Sower/semeur : c'est l'utilisateur qui essaime des informations via des codes uniques heading/rubrique : Ce sont les rubriques dans lesquelles un “semeur” classe ces informations item/info : ce sont les informations unitaires qu'un “semeur” souhaite partager

Chacun de ces objet est identifiable de manière unique via un code. ainsi, un “semeur” pourra partager :

• l'accès à des informations le concernant via son code unique
• l'accès à un ensemble d'informations liées à une de ces rubrique
• l'accès à une information isolée au sein de ses rubriques

• id
• nom (surnom)
• email (qui le définit comme utilisateur unique de l'application)
• code (unique et délivré par findout, il permet de partager ses infos sans que ça transparaisse dans l'échange)
• date de création
• date de dernière modification

• id
• owner/sower (le propriétaire de la rubrique)
• nom
• code (unique et délivré par findout, il permet de partager les infos de toute l'arborescence de la rubrique)
• contenu (la rubrique peut aussi délivrer un contenu)
• date de création
• date de dernière modification

A noter :

• le nom de la rubrique est unique pour un semeur donné

• id
• heading (la rubrique qui contient l'info)
• nom
• code (unique et délivré par findout, il permet de partager spécifiquement cette info)
• contenu (le contenu spécifique de l'info)
• validfrom (date à partir de laquelle l'info est accessible)
• validuntil (date à partir de laquelle l'info n'est plus accessible)
• countdown (o/n, définit si l'on permet d'afficher un compte à rebours si on réclame l'info trop tôt)
• toolatewarning (o/n, définit si l'on prévient l'utilisateur que l'info qu'il a sollicitée est révolue)
• date de création
• date de dernière modification

A noter :

• le nom de l'info est unique pour une rubrique donnée

Tous les codes sont regroupés dans une table spécifique pour s'assurer de l'unicité du code quelquesoit son usage.

• id
• code
• date de creation
• date de dernière modification

Pour des raisons de statistiques voir si on rajoute un champs hit pour comptabiliser le nombre d'accès à ce code.

Sinon ce sera dans une table 1←→1.

====== Tables annexes ======

Recueille les avis des utilisateurs

• id
• nom d'utilisateur (sewer si connecté)
• note o/n ou x/5 ou x/10
• commentaire pour expliquer la note
• date de creation
• date de dernière modification

On peut rajouter un champs publication, si on met en place un process de moderation

Pour gérer les notifications vers les users avec compte.

• id
• sower
• notification (peut être un code)
• acquittement (lu par l'utilisateur)
• date de création
• date de dernière modification

Pour stocker les codes que l'on a reçu afin de ne pas les disperser ou même les perdre

• id
• sewer
• code
• note personnelle (initialisée par le titre originel du code)
• date de création
• date de dernière modification

====== Tables système ======

Une table dissociée pour stocker les données d'authentification des utilisateurs. Permet de ne pas les visualiser si on a accès à la table sewer.

• id
• sower
• password
• authent externe (ex: google)
• authent pour push (pour les notifications mobile, à confirmer)
• date de création
• date de dernière modification

• id
• sewer
• token
• date de création
• date de dernière modification

• id
• sewer
• activated (peu ainsi recevoir l'accès admin temporairement)
• date de création
• date de dernière modification