Pour les profils d'auteur non membre, je voyais plutôt une gestion publique. Une fois l'auteur rentré tout le monde (ou seulement des modérateurs) peuvent modifier les infos. Je ne vois pas de raison que celui qui a enregistré le profil est plus de droit que les autres.
Mon idée par rapport aux tables avh été la simplification à l’extrême. Éviter qu'un même champ ne soit présent dans deux tables différentes. Maintenant oui on peut recopier un certain nombre de champ afin d'être performant (maintenant ce n'est pas mon approche préféré). On sera peut-être obligé à chaque fois de faire une jointure pour la révision courante. Donc peut-être que l'on gagne rien.
Pour la release_time, je pense que l'on pourra ajouter automatiquement un tag PROJET et l’enlevé lors de la première release. Ce qui permet d'introduire mon idée de tag automatique. Impossible à ajouter manuellement sauf pour les admin/modérateurs. Modifié uniquement par le serveur. Il suffit de rajouter un booléen automatic dans la table Tag.
Pour refactoring, est ce que ce serai plus normal qu'un auteur fasse dans ce cas là une nouvelle version ?
La différence entre description et update_message c'est que update_message est juste un message cours lors d'un changement de l'avancement (genre je viens d'ajouter 33 paragraphes). La description décrit le changement global de la révision.
Ta classe avh_view je ne l'avais pas vue, elle n'est présente sur aucun diagramme. Par contre je pense qu'il faudra prend en compte plus de cas et pas uniquement le nombre de vue de la page avh. Pour ça on a deux choix : plusieurs tables, soit une table générale. Pour les fichiers, je pense pas que compter les visiteurs uniques soit utile.
Pour le champ gratuit dans la table avh_file, on ne compte pas faire une option de e-commerce non ? Donc je vois pas l'utilité.
Pour les fichiers, le nom de fichier n'a pas d'intérêt. Pour la simple bonne raison que l'on utilisera url_key pour ça. Sinon cela fait double usage.
Pour les images, le alt sera certainement un truc à faire automatiquement. Et je pense que si on garde qu'un seul champ, le mieux et de garder url_key. Le but de type_image_id et de différencier les logos, des couvertures, des avatars, ...
EDIT : Correction de quelque petites fautes.
Mon idée par rapport aux tables avh été la simplification à l’extrême. Éviter qu'un même champ ne soit présent dans deux tables différentes. Maintenant oui on peut recopier un certain nombre de champ afin d'être performant (maintenant ce n'est pas mon approche préféré). On sera peut-être obligé à chaque fois de faire une jointure pour la révision courante. Donc peut-être que l'on gagne rien.
Pour la release_time, je pense que l'on pourra ajouter automatiquement un tag PROJET et l’enlevé lors de la première release. Ce qui permet d'introduire mon idée de tag automatique. Impossible à ajouter manuellement sauf pour les admin/modérateurs. Modifié uniquement par le serveur. Il suffit de rajouter un booléen automatic dans la table Tag.
Pour refactoring, est ce que ce serai plus normal qu'un auteur fasse dans ce cas là une nouvelle version ?
La différence entre description et update_message c'est que update_message est juste un message cours lors d'un changement de l'avancement (genre je viens d'ajouter 33 paragraphes). La description décrit le changement global de la révision.
Ta classe avh_view je ne l'avais pas vue, elle n'est présente sur aucun diagramme. Par contre je pense qu'il faudra prend en compte plus de cas et pas uniquement le nombre de vue de la page avh. Pour ça on a deux choix : plusieurs tables, soit une table générale. Pour les fichiers, je pense pas que compter les visiteurs uniques soit utile.
Pour le champ gratuit dans la table avh_file, on ne compte pas faire une option de e-commerce non ? Donc je vois pas l'utilité.
Pour les fichiers, le nom de fichier n'a pas d'intérêt. Pour la simple bonne raison que l'on utilisera url_key pour ça. Sinon cela fait double usage.
Pour les images, le alt sera certainement un truc à faire automatiquement. Et je pense que si on garde qu'un seul champ, le mieux et de garder url_key. Le but de type_image_id et de différencier les logos, des couvertures, des avatars, ...
EDIT : Correction de quelque petites fautes.
Netwak