J'ai reconfiguré à 2. :P
Hors ligne
rvelices a écrit:
Et un dernier point sans importance majeure ... les regles des codages qq part disent qu'il faut utiliser 2 espaces comme tabulation. Hors sur ton editeur t'utilises des tabs (probablement configures a 8 espaces)...
On dirait une des mes remarques !! :-)
Hors ligne
Les règles de codage de Piwigo, nous devons tous les respecter.
Cependant, les règles ne doivent pas être perçues comme des contraintes au développement de plugins.
Ceci étant dit, les membres de l'équipe doivent montrer l'exemple, et pour ça je ne suis pas bon du tout car je fais volontairement le contraire actuellement.
(Pan sur le ...).
Hors ligne
nicolas a écrit:
VDigital a écrit:
Quid des commentaires? Je crois que cela ne change rien...
P@t?
(Il me semble que c'est toi qui avait proposé ça...)Je pense aussi que ça ne change rien. Un utilisateur (un vrai, pas un ivité) pourra éditer/supprimer ses messages que s'il lui appartienne, en se basant sur son user_id et sur author_id. Pour le cas de l'utilisateur ayant posté avec un pseudo et s'enregistrant après sous le même pseudo, il ne pourra pas editer/supprimer ses anciens messages.
Tu peux nous faire un 83-database.php qui renseigne author_id s'il est null?
Tu fais un requête qui fait la correspondance author et id dans la table des users et si la le lien n'existe, tu mets par défaut le id du guest!
Hors ligne
C'est du chinois pour 95% des utilisateurs (mais c'est une bonne idée).
Hors ligne
rub a écrit:
nicolas a écrit:
VDigital a écrit:
Quid des commentaires? Je crois que cela ne change rien...
P@t?
(Il me semble que c'est toi qui avait proposé ça...)Je pense aussi que ça ne change rien. Un utilisateur (un vrai, pas un ivité) pourra éditer/supprimer ses messages que s'il lui appartienne, en se basant sur son user_id et sur author_id. Pour le cas de l'utilisateur ayant posté avec un pseudo et s'enregistrant après sous le même pseudo, il ne pourra pas editer/supprimer ses anciens messages.
Tu peux nous faire un 83-database.php qui renseigne author_id s'il est null?
Tu fais un requête qui fait la correspondance author et id dans la table des users et si la le lien n'existe, tu mets par défaut le id du guest!
Du style [Subversion] r3459 ;-)
Hors ligne
Autre petite remarque, personnellement, j'aurais mis par défaut le droit de modifier son propre commentaire. Et aussi de le supprimer.
Hors ligne
rub a écrit:
Du style [Subversion] r3459 ;-)
Je suis mitigé sur ce commit....
Si Robert (encore lui) a enregistré un commentaire, et qu'il existe un user "Robert", rien ne dit que c'est le meme qui a fait ce commentaire.
Par contre, on pourrait comparer la date du commentaire et la date d'enregistrement de l'utilisateur... si le commentaire est plus récent que l'enregistrement de l'utilisateur, alors, c'est ok.
Cela ne règle pas le problème des utilisateurs enregistrés, supprimés, re-enregistrés, mais bon, c'est marginal.
Dernière modification par P@t (2009-06-25 18:29:24)
Hors ligne
Pas tout à fait d'accord.
Si le commentaire à moins de 5 min, peut-être et uniquement si c'est le dernier commentaire de la galerie...
Hors ligne
P@t a écrit:
rub a écrit:
Du style [Subversion] r3459 ;-)
Je suis mitigé sur ce commit....
Si Robert (encore lui) a enregistré un commentaire, et qu'il existe un user "Robert", rien ne dit que c'est le meme qui a fait ce commentaire.
Par contre, on pourrait comparer la date du commentaire et la date d'enregistrement de l'utilisateur... si le commentaire est plus récent que l'enregistrement de l'utilisateur, alors, c'est ok.
Cela ne règle pas le problème des utilisateurs enregistrés, supprimés, re-enregistrés, mais bon, c'est marginal.
C'est vrai... mais de toute façon, on aura jamais le résultat parfait...
Et c'est sans compter les changements de username (même si c'est pas possible de base dans l'appli mais simple comme bonjour en phpmyadmin).
Mais, perso, je préfère que Robert L'utilisateur puisse modifier le commentaire de Robert l'invité... Plutôt que l'ensemble des utilisateurs ne puissent pas modifier leur anciens...
Hors ligne
VDigital a écrit:
Pas tout à fait d'accord.
Si le commentaire à moins de 5 min, peut-être et uniquement si c'est le dernier commentaire de la galerie...
Tu parles de l'option de modifier par défaut.
Si on met une tempo, ca va être lourd quand même... Faisons au plus simple...
Hors ligne
Je ne veux pas de tempo mais l'inverse.
On ne supprime pas un message qui a été lu, référencé par Google, pour lequel certains ont posté également en tenant compte de ce qui avait été déjà mis.
"option de modifier par défaut": Non, je parle bien du seul cas possible de suppression (autre qu'un admin).
AMHA un visiteur (membre) pourrait supprimer son message si et seulement si son commentaire est récent, et que ce message est bien le dernier commentaire.
Hors ligne
VDigital a écrit:
Je ne veux pas de tempo mais l'inverse.
On ne supprime pas un message qui a été lu, référencé par Google, pour lequel certains ont posté également en tenant compte de ce qui avait été déjà mis.
On est quand même censé être maitre de ce qu'on a écrit...
Si j'écris une vacherie sur un ministre, que certains commentent... je ne pourrais pas retirer mon message et risque d'aller en prison ... ;-)
VDigital a écrit:
"option de modifier par défaut": Non, je parle bien du seul cas possible de suppression (autre qu'un admin).
AMHA un visiteur (membre) pourrait supprimer son message si et seulement si son commentaire est récent, et que ce message est bien le dernier commentaire.
Dernier commentaire de quoi? De l'image? Ou des commentaires de l'utilisateur? Ou des deux?
Mais, je comprends ce que tu veux dire...
Mais pour moi, Piwigo doit rester simple à utiliser et à comprendre => ce qui a été fait dans la version de base est suffisant pour une grande majorité des galeries...
Par contre, un plugin implémentant les gestions un peu plus compliqués, que tu évoques, serait le bienvenu et utile pour les galeries un peu plus "pro" (les galeries qui veulent être référencées par exemple)...
Criss, à ta place, je ferais en sorte ton plugin intègre les modifs de la prochaine release. Mais, tu y rajoutes d'autres fonctionnalités (comme les exigences de VDigital)...
Le top serait de la faire tout en permettant une intégration aisée dans le prochaine version... en gros, avec la version 2.1 de Piwigo, tu supprimes le code en doublon de ton plugin et celui reste fonctionnel.
Hors ligne
rub a écrit:
Mais, perso, je préfère que Robert L'utilisateur puisse modifier le commentaire de Robert l'invité... Plutôt que l'ensemble des utilisateurs ne puissent pas modifier leur anciens...
Je suis pas du tout d'accord.... je préfère encore que les anciens commentaires ne soient pas modifiables!
Mais de toute facon, je propse simplement une vérification de la date d'enregistrement du commentaire et de l'utilisateur. Donc dans la très grande majorité des cas, cela ne posera pas de problèmes, et les utilisateurs pourront modifier leurs anciens commentaires.
Dernière modification par P@t (2009-06-26 10:50:24)
Hors ligne