🌍
Français
Vu comme çà... Si tu veux, on peut essayer, dans un premier temps sans que tu publies une nouvelle version de Ac_C. Je prendrai sur le SVN pour tester. Si çà devait poser trop de problèmes supplémentaires, il serait facile de revenir en arrière.
Eric a écrit:
flop25 a écrit:
je pense que je peux éviter la demande d'âge après inscription si ton plugin est activé, et éviter l'affichage du bloc menu qui va demander l'âge, si ton plugin existe et qu'utilisateur est "waiting". C'est le plus simple pour nous deux non ?
Ce serait plus simple mais dans ce cas, le plugin Ad_C ne présenterait plus d'intérêt si les users qui s'inscrivent ne peuvent préciser leur statut :-/
Je n'ai pas eu le temps jusqu'ici de réfléchir plus avant au problème donc je m'y mets. ;-)
Nan mais juste après leur validation, les users pourront préciser leur statut
flop25 a écrit:
je pense que je peux éviter la demande d'âge après inscription si ton plugin est activé, et éviter l'affichage du bloc menu qui va demander l'âge, si ton plugin existe et qu'utilisateur est "waiting". C'est le plus simple pour nous deux non ?
Ce serait plus simple mais dans ce cas, le plugin Ad_C ne présenterait plus d'intérêt si les users qui s'inscrivent ne peuvent préciser leur statut :-/
Je n'ai pas eu le temps jusqu'ici de réfléchir plus avant au problème donc je m'y mets. ;-)
je pense que je peux éviter la demande d'âge après inscription si ton plugin est activé, et éviter l'affichage du bloc menu qui va demander l'âge, si ton plugin existe et qu'utilisateur est "waiting". C'est le plus simple pour nous deux non ?
J'ai étudié ce qui serait faisable côté UAM pour assurer la compatibilité avec Ad_C. L'idée serait, si Ad_C est existant, de mettre dans une sorte de cache la valeur du groupe Ad_C pour chaque user qui s'inscrit et de la restituer lorsqu'il a validé son inscription.
Concrètement, cela nécessiterait une évolution ou un modification de mon modèle de données en bdd (ajouter ou modifier une table de UAM) et de mettre en place le système de contrôle et de traitement... Pas une mince affaire compte-tenu de la complexité actuelle du plugin :-/
@flop25 : Si tu entrevois une approche plus simple via Ad_C, franchement, çà m'arrangerait. Sinon, ben je ferai pour le mieux pour assurer la compatibilité à partir de UAM mais...
Eric a écrit:
Je confirme : C'est bien mieux ;-) Bien joué !
Bravo flop25 !
Eric a écrit:
Plus de notices et les users peuvent changer leur statut. Mais, maintenant que cela fonctionne, un nouveau problème de compatibilité avec UAM apparait :-(
(...)
L'intérêt de la validation des inscriptions de UAM disparait donc. Et je ne vois pas comment faire cohabiter le fonctionnement de ces deux plugins.
Pasdbol :-( ...
Bon courage à tous les deux :-/ ... (Enfin, si Éric a besoin de modifier UAM.)
Pour info (et c'est une bonne nouvelle ^^), Ad_C fonctionne parfaitement sur Piwigo 2.2.0RC3. Je pense que tu peux positionner ta dernière version en compatible avec la RC3.
Je confirme : C'est bien mieux ;-) Bien joué !
Plus de notices et les users peuvent changer leur statut. Mais, maintenant que cela fonctionne, un nouveau problème de compatibilité avec UAM apparait :-(
UAM permet de gérer les validations d'inscription en jouant sur l'appartenance à un groupe. Typiquement, lorsqu'un user s'inscrit, il est versé dans un groupe "d'attente" qui lui offre une visibilité restreinte de la galerie tant qu'il n'a pas validé son inscription. Lorsque fait, il est versé dans un autre groupe qui lui permet une visibilité plus totale (en fonction des réglages fait pas l'admin).
Ad_C fait de même mais en fonction du statut choisi par le user à son inscription (également après). Et c'est là que çà me pose un problème. J'explique par un exemple dans un cas extrême :
- Une galerie utilisant les deux plugins UAM et Ad_C.
* UAM est configuré pour que les nouveaux inscrits non validés soient associé à un groupe "waiting" qui ne leur donne aucune visualisation des albums. Lorsque les inscriptions sont validées, les users sont retirés de "Waiting" et associés à un nouveau groupe "Validated" qui leur donne la visualisation sur toute la galerie.
* Ad_C est configuré pour que le groupe "+18" autorise la visualisation de tous les albums sans restriction, "16-17" restreint la visualisation de quelques albums jugés "trop sensibles" et "nothing" restreint encore plus pour ne permettre la visualisation que des albums "tout public".
- Dans cette configuration, lorsqu'un user s'inscrit et qu'il choisit le statut "+18", il a la visualisation de tous les albums même s'il n'a pas validé son inscription...
L'intérêt de la validation des inscriptions de UAM disparait donc. Et je ne vois pas comment faire cohabiter le fonctionnement de ces deux plugins.
extension:141 nouvelle révision qui ira bien mieux que les autres normalement
Oh mon dieu je viens de me rendre compte que reprendre son premier plugin, c'est comme un artiste qui revoit ses dessins d'enfance
hum ! ya pas mal de choses à (re)faire
flop25 a écrit:
Merci
je vais m'arrêter là pour aujourd'hui
Ok, je te donne une dernière indication pour quand tu t'y remettras ;-)
Je n'ai activé que le plugin Ad_c sur ma galerie, je procède à l'inscription d'un nouveau user "test3" pour sortir du contexte d'un user déjà existant. Ce nouveau user déclare être +18. L'inscription se passe bien mais dès le retour sur la page d'index j'ai les même notices php concernant la variable "statut" et le même problème si ce user veux changer son statut.
En espérant que cela t'aideras à débugger :-)
Merci
je vais m'arrêter là pour aujourd'hui
flop25 a écrit:
tu dis ton user de test : est-ce qu'il existe d'avant la réinstall/désinstall d'ad_c ?
Oui
flop25 a écrit:
Si oui désinstalle ad_c et regarde si :
les groupes sont encore là
Les groupes +18, 16-17 et Nothing ne sont plus présents
flop25 a écrit:
les utilisateur 16/18 sont encore là
Les utilisateurs 16 et 18 sont bien supprimés
flop25 a écrit:
et le résultat de SELECT group_id FROM phpwebgallery_user_group WHERE user_id IN ('617')
Résultat : 1 ligne trouvée -> group_id = 8 ce qui correspond au groupe d'utilisateurs par défaut configuré sur ma galerie. Donc normal pour moi.
tu dis ton user de test : est-ce qu'il existe d'avant la réinstall/désinstall d'ad_c ?
Si oui désinstalle ad_c et regarde si :
les groupes sont encore là
les utilisateur 16/18 sont encore là
et le résultat de SELECT group_id FROM phpwebgallery_user_group WHERE user_id IN ('617')
flop25 a écrit:
la marche à suivre parfaite serait :
désactivation de UAM -> OK ainsi que tous les autres plugins. Il ne reste que Adult_Content d'actif.
désinstalle puis réinstall de Adult_content -> OK. Par mesure de sureté, je l'ai totalement désinstallé (fichiers compris) pour mieux le réinstaller à partir du dépot SVN.
Si tout va bien c'est UAM -encore pfff ;) -, sinon c'est autre chose
Bah, non. C'est autre chose... Lorsque mon user de test, membre du groupe "Nothing" se connecte, il y a ce message:
Notice: Undefined variable: statut in E:\www\monsite\piwigo\plugins\adult_content\class.inc.php on line 281
S'il se rend sur la page de modification de son statut, c'est ce message qui apparait (différent du permier):
Notice: Undefined variable: statut in E:\www\monsite\piwigo\plugins\adult_content\charte_user.php on line 57
Et s'il souhaite changer de statut :
[mysql error 1062] Duplicate entry '130-617' for key 'PRIMARY'
UPDATE phpwebgallery_user_group SET group_id='130' WHERE user_id IN ('617')
#1 my_error E:\www\monsite\piwigo\include\dblayer\functions_mysql.inc.php(90)
#2 pwg_query E:\www\monsite\piwigo\plugins\adult_content\charte_user.php(94)
J'ai bien vérifié que UAM (surtout !) n'est plus actif. Donc ce n'est pas lui le problème (ouf ! ;-p)...