🌍
Français
P@t a écrit:
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!
Hummm ;-)
Bref...
P@t a écrit:
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.
En tout cas, le test est simple à faire, j'ai donc modifié la requête... (j'espère qu'elle passe sur toutes les versions de mysql supportées par Piwigo)...
[Subversion] r3464
rub a écrit:
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.
Pour le moment il ne les intègre pas, puisqu'il est en production et que la 2.1 est en cours de développement ;)
Mais j'ai normalement fait un design me permettant d'aisément les intégrer, pas de soucis là dessus. :-O
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.
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.
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.
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...
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...
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...
rub a écrit:
Autre petite remarque, personnellement, j'aurais mis par défaut le droit de modifier son propre commentaire. Et aussi de le supprimer.
+1
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.
Autre petite remarque, personnellement, j'aurais mis par défaut le droit de modifier son propre commentaire. Et aussi de le supprimer.
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 ;-)
C'est du chinois pour 95% des utilisateurs (mais c'est une bonne idée).
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!
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 ...).