Citation :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.
Il faut que la fiche soit modifiable par plus que les modérateurs, sinon on va retomber dans le piège du Xhoromag actuel, où Oiseau doit tout faire lui-même. Et je crains le pie si on laisse les profils en open bar.
En fait, les droits supplémentaires au créateur sont un intermédiaire correspondant à la situation la plus classique : la traduction. Le traducteur va créer le profil de l'auteur original et peut-être même le mettre à jour en fonction des nouvelles traductions (Oiseau a par exemple traduit plusieurs séries). Dans le cas actuel, lors de la migration du site, ce droit spécial sera accordé à ceux qui ont rempli la base de données, pour qu'il puisse corriger leurs propres erreurs si besoin est, critère qui m'a déjà été demandé plusieurs fois.
Citation :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.
Pas une mauvaise idée. Venant également de me rappeler un principe de base de l'informatique (Premature optimization is the root of all evil), après m'être foutu des baffes à moi-même (je n'ai pas respecté un principe que j'adore répété), je laisse tomber toutes ces histoires de champs dupliqués pour l'instant. On les vire, on fera des jonctions, et, quand tout marchera à la fin, on optimisera si besoin est.
Citation :Pour refactoring, est ce que ce serai plus normal qu'un auteur fasse dans ce cas là une nouvelle version ?Désolé, toujours pas compris.
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.
Citation :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.J'aime bien compter les visiteurs uniques, surtout que j'ai tendance à ouvrir tous mes pdf en double ou plus. Pour l'instant, je pense que l'on peut reporter la création de la ou des table(s) de statistiques à la fin du projet, vu qu'elles sont relativement indépendantes du reste. Y'a plus urgent quoi.
Citation :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é.On ne fait pas d'e-commerce, mais cela obéit à une contrainte qui existe déjà : des avh présentes sur Xhoromag, mais dont l'un des supports est payant (liens externes uniquement). Exemple : Les Noces de Bayshu. Rajouter ce booléen nous permet donc de définir les aventures qui disposent d'au moins un support gratuit comme gratuite (exemple : aventure disponible en PDF gratuit et livre payant) et celles vraiment payantes (exemple : Héros). J'exècre ces sites qui mélangent aléatoirement contenu gratuit et payant.
Citation :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.Oué, des problèmes de compréhension bêtes : on pensait à la même chose, mais sans se comprendre.
Citation :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, ...Va pour un alt auto. Toujours pas convaincu par type_image_id par contre. Pour identifier tous les logos de série par exemple, il suffit de faire une jonction entre la table collection et image sur collection.image_id=image.id. Pas besoin d'un champ supplémentaire.
EDIT : pour les modifs sur lesquelles on est d'accord, n'hésite pas à modifier directement le .mwb.
