Dsl

J'avais été faire un tour sur mantis mais pas sur la page dédiée à ce plugin.
On ne m'y reprendra plus.

Merci.

J'ai également ajouté [Bugtracker] ticket 2054 dans ma todo list. Il est vrai qu'une information à l'utilisateur lorsque son compte est validé manuellement par l'admin est une bonne idée.

L'option de sensibilité à la casse de Piwigo ne se gère pas depuis la table #_config.
Regardes dans ton fichier config_default.inc.php (via le plugin LocalFiles Editor) la ligne "$conf['insensitive_case_logon'] =". Si la valeur est True, c'est que tu as modifié le fichier de conf par défaut.. Et c'est "mal". ^^

Normalement, par défaut, cette option de config devrait être : $conf['insensitive_case_logon'] = false;

Si tu veux modifier le comportement de Piwigo, utilises le plugin LocalFiles Editor pour créer (si ce n'est déjà fait) un fichier de configuration personnel local/config/config.inc.php dans lequel tu recopieras la ligne suivante (texte d'explication à traduire en FR au besoin):

// Define if logins must be case sentitive or not at users registration. ie :
// If set true, the login "user" will equal "User" or "USER" or "user",
// etc. ... And it will be impossible to use such login variation to create a
// new user account.
$conf['insensitive_case_logon'] = false;

Rappel : Dans tous les cas, on ne touche jamais au fichier config_default.inc.php !!

Sinon, tu remarqueras qu'il n'y a aucune allusion à UAM dans mes propos ci-dessus ;-))

Whiler a écrit:

Toujours est-il que :
Il est en base, dans le default et dans le local à true....
Le local, j'viens de le modifier... je ne pense pas qu'il faille purger un cache pour que cela fonctionne ?

Non, pas de cache à vider si ce n'est peut-être celui de ton navigateur dans les cas extrêmes (celui-ci n'en est pas un)... Mais je ne comprends toujours pas où tu trouves "insensitive_case_logon" dans ta table de configuration. Quel est le contenu des champs param, value et comment où tu as cette entrée ?

Whiler a écrit:

Hum, autre idée...  les users existants...  ils fonctionnent ? c'est pas une sauvegarde en lowercase qui est comparé avec lowercase de la valeur saisie, mais bien les deux en lowercase au moment de la comparaison ? (si j'suis pas clair... tu le dis ;o)))

C'est très clair ;-)
Et il n'y a aucun souci avec les users déjà inscrits. La comparaison se fait entre le lowercase de la valeur saisie et sur le lowercase de la valeur en base. Mais là encore, on ne parle que de Piwigo et pas du plugin UAM.
Ce serait vraiment mieux, si tu continues à avoir des problèmes sur ce point précis de la casse au logon, d'ouvrir un topic dédié dans la section "Utilisation".
1- Cà permettra à d'autres qui pourraient être dans ton cas de trouver plus facilement la réponse
2- On évitera de poursuivre le HS sur le topic dédié au plugin UAM ;-)

Whiler a écrit:

Il y a quelque temps... lorsque j'avais constaté le problème, j'avais moi-même inséré cette entrée dans la table... cela ne l'a jamais résolu, mais je ne l'avais purgé...

Alors tu peux purger çà, c'est sans intérêt et risque de porter confusion.

Whiler a écrit:

Ok.. Pas de soucis... FYI, j'ai désactivé UAM...
Et voici le topic en question, Insensible à la casse...... (mais j'ai rêvé ou c'était une option d'UAM par le passé ?

Oui, par le passé, avant que la fonction soit intégrée à Piwigo. Ensuite, elle n'avait plus raison d'être. La suite sur l'autre topic.

Mais pourquoi avoir désactivé UAM ? Tu l'utilisais que pour cette ancienne fonction de sensibilité à la casse ? Si même désactivé, le problème subsiste, c'est que la réponse est ailleurs.

La nouvelle version 2.16.0 du plugin est disponible !

Les bugs corrigés:
- [Bugtracker] ticket 2046 - L'utilisation de l'option Piwigo $conf['insensitive_case_logon'] = true ne fonctionnait pas lorsque UAM est actif.
- [Bugtracker] ticket 2053 - La validation manuelle des inscriptions ne fonctionnait pas correctement.

Les améliorations:
- [Bugtracker] ticket 2011 - Avant, les champs de texte étaient en lecture seule tant qu'on n'a pas activé l'option correspondante et sauvegardé au préalable. Ce fonctionnement, destiné au départ à éviter les fauses manipulations pouvant engendrer des pertes de données) était trop lourd et sujet à incompréhensions. Maintenant, ces champs sont masqués et apparaissent lorsque les options sont validées.

Les nouveautés:
- [Bugtracker] ticket 2054 - Possibilité de générer un email au contenu personnalisable lorsqu'un admin / webmaster valide manuellement les inscriptions.
- [Bugtracker] ticket 2056 - (voir explications détaillées ci-dessous) Automatisation des traitements sur les utilisateurs fantômes (qui ne sont pas revenus visiter la galerie depuis x temps). Ceci est un début pour l'automatisation des actions et sera étendu par la suite au traitement des utilisateurs en attente de validation.


A propos de l'automatisation des tâches:
La première difficulté, en l'absence de cron, a été de trouver un évènement déclencheur. J'ai opté pour l'identification à la galerie qui est la première action physique et exploitable sur une galerie. Ainsi, dès qu'un utilisateur, quel qu'il soit, se connecte, des contrôles sont lancés sur les utilisateurs fantômes (gérés dans le Ghost Tracker).

Pour chaque utilisateur qui n'est pas revenu visiter la galerie après x jours (paramétrables dans le plugin):
- S'il n'a jamais fait l'objet d'un email de relance
       -> L'utilisateur est rétrogradé dans un groupe et/ou statut restreignant son accès à la galerie (sur le même principe des groupes/statuts d'attente avant validation d'inscription).
       -> L'utilisateur peut être notifié par mail de cette rétrogradation avec la possibilité de revalider son inscription par un lien présent dans l'email. Ceci vaut comme email de relance.
- S'il a déjà fait l'objet d'un email de relance
       -> Suppression du compte sans autre préavis. Une future évolution du système permettra d'envoyer un email de notification de suppression de compte.

Cas particulier (et normalement rare mais à prendre en considération tout de même ^^) de l'utilisateur dont le compte a expiré et qui déclenche lui-même sa suppression ou sa rétrogradation (pas de bol mais c'est la loi de Murphy !):
- S'il est rétrogradé -> Il génèrera lui-même l'émission du mail de notification avec la clé de réactivation et son accès sera immédiatement impacté par les restrictions appliquées. Si [extension by plg] PWG Stuffs est utilisé pour avertir les utilisateurs en attente de validation, l'utilisateur rétrogradé retrouvera ce même message lors de sa connexion.
- S'il est supprimé -> Son accès le redirige vers une page lui indiquant que son compte a été détruit et, éventuellement, les raisons de cette destruction. Le contenu de cette page est personnalisable dans l'interface d'administration du plugin.

Voila, pour l'explication sur le fonctionnement de l'usine ;-)
J'ai essayé de tester tous les cas de figure mais il est possible que je sois passé à côté de certains. J'attends donc vos retours, pour ceux qui sont intéressés par ces nouvelles fonctions.


[edit]
La mise en oeuvre des automatismes peut ralentir sensiblement le temps de réponse de la galerie sur les identifications d'utilisateurs. Vu le nombre de contrôles et d'actions à réaliser, c'est un peu normal. Mais je tâcherai d'optimiser tout cela lors des prochaines versions. ;-)
[/edit]

Dernière modification par Eric (2010-12-16 18:47:56)

Whiler a écrit:

Cool ! t'as du temps pour autre chose maintenant ;o)

;-)
Si tu jettes un oeil sur le bugtracker de UAM, tu verras qu'il me reste pas mal de boulot ! Mais je vais pouvoir effectivement me consacrer un peu plus à LCAS ^^

Pour cause de changements importants dans le plugin et le portage sur Piwigo 2.2.0-RC, j'ai publié une version en RC pour tester avec la RC de Piwigo. Comme toutes version en RC, à n'utiliser qu'à des fins de tests dans un environnement prévu pour cela.

Voici la liste des bugs corrigés et évolutions apportées par cette version :
[Bugtracker] ticket 1666 [edit] Uniquement à partir de Piwigo 2.2-RC3 [/edit]
[Bugtracker] ticket 2045
[Bugtracker] ticket 2055
[Bugtracker] ticket 2072
[Bugtracker] ticket 2140
[Bugtracker] ticket 2186
[Bugtracker] ticket 2188
[Bugtracker] ticket 2192

Dernière modification par Eric (2011-02-25 18:43:21)