Whiler a écrit:

@ Eric : ([Subversion] r9389)

J'ai re-implémenté la vérification de l'existence d'un login depuis l'interface de LCAS...

J'ai supprimé le SELECT car celui-ci ne tenait pas compte de la règle définie dans les options...

Les quelques tests que j'ai effectués ont été concluants ;o)

J'y ai cru moi aussi mais, finalement, çà ne fonctionne pas complètement :-(
Le contrôle d'unicité fonctionne pour les username tenant compte des règles définies mais si on renomme un user avec un nom totalement différent et existant en bdd (par exemple "admin"):

[mysql error 1062] Duplicate entry 'admin' for key 'users_ui1'

              UPDATE piwigo_users
              SET username="admin"
              WHERE id=4
              LIMIT 1
              ;

#1    my_error E:\www\PWG_2.2-RC3-MySql5.5.8\include\dblayer\functions_mysql.inc.php(88)
#2    pwg_query E:\www\PWG_2.2-RC3-MySql5.5.8\plugins\LCAS\admin\LCAS_admin.php(112)
#3    include_once E:\www\PWG_2.2-RC3-MySql5.5.8\admin\plugin.php(56)
#4    include E:\www\PWG_2.2-RC3-MySql5.5.8\admin.php(224)

J'ai pris un cas particulier (le compte admin de ma galerie de test) mais c'est le même problème avec un autre compte:
- J'ai un conflit entre "béatrice" et "BÉATRICE"
- J'ai un compte "toto" existant et n'entrant pas en conflit
- Je renomme "BÉATRICE" en "toto"
Et j'ai le beau message d'insulte...

[edit] [Bugtracker] ticket 2208 [/edit]

Dernière modification par Eric (2011-02-27 17:35:31)

Eric a écrit:

[Subversion] r9401

En cumulant la recherche de doublons avec les règles configurées pour LCAS et une simple recherche par SELECT d'un username existant, il n'y a plus d'erreur "Duplicate entry" et le renommage des username en conflit fonctionne ;-)

C'est également vrai pour ce cas ?

- J'ai un conflit entre "béatrice" et "BÉATRICE"
- J'ai un compte "tôtô" existant et n'entrant pas en conflit
- Je renomme "BÉATRICE" en "toto"

Je n'ai pas vérifié... mais est-ce que l'inscription de nouveaux utilisateurs est gérée en fonction de la règle choisie ?

(Si oui, il doit simplement falloir utiliser la même fonction/mécanisme, ou alors il est peut-être aussi buggé ?)

Si je trouve 5mn (au moins 15 ;o)), je regarderai... mais je manque cruellement de temps (d'où les messages où je me contente de soumettre des idées...)

Je pense avoir trouvé ce qui cloche pour [Bugtracker] ticket 2208 : On fait appel à LCAS_change_case() pour transformer le username modifié selon les règles en place mais on ne fait pas la même chose pour les username déjà présents en bdd. Du coup, la requête ne sait pas retrouver ses petits.

Il faudrait utiliser la fonction qu'on appelle pour le contrôle des inscriptions et identifications : LCAS_SearchCaseUsername(). Elle retourne un username si déjà présent en bdd et "matchant" les règles de sensibilité.
Mais si aucun username n'est déjà présent (c'est ce qu'on cherche dans ce cas précis), que retourne la fonction ? Un tableau vide ?

J'ai essayé de coder "Si LCAS_SearchCaseUsername() retourne un tableau vide alors le renommage du username en conflit est OK sinon NOK". Sans grand succès pour l'instant.

Ayé ! Avec [Subversion] r9474, je pense avoir résolu le [Bugtracker] ticket 2208 mais j'attends vos retours de test avant de fermer le bug.
Comme annoncé précédemment, je me suis basé sur le fonctionnement de LCAS_SearchCaseUsername(). J'ai fait plusieurs tests dans différentes configurations et çà a l'air de coller mais j'ai pu zapper des cas particuliers.

Il y a tout de même quelque chose qui me gène dans mon fix (et, par extension, dans LCAS_SearchCaseUsername()) : Une requête remonte tous les username présents dans la table #_users pour faire le comparatif en concordance avec les règles de LCAS. Cà va bien lorsqu'on n'a que quelques users mais je suis inquiet pour les performances lorsqu'on a plusieurs centaines / milliers d'utilisateurs inscrits. On remonte systématiquement tout ce beau monde dans un tableau.

On doit pouvoir optimiser çà, non ?

Whiler a écrit:

Eric :

Sans dénormaliser le modèle de la base d'origine en ajoutant une colonne pour le format converti, je ne vois hélas pas comment... (ou en ajoutant une fonction à la base de données pour effectuer une conversion comme le fait notre fonction... lol... installation du plugin, 2 semaines en admettant qu'on ait les droits)....

J'avais également pensé à cela... mais je ne suis pas sûr que des métriques existent quelque part avec le nb de users enregistrés sur des sites utilisant PWG...

Sinon, plutôt que de renvoyer/parcourir un tableau... faire une boucle par ligne... mais dans ce cas, ce n'est plus la mémoire qui morfle mais les accès php<->base...

Mouais... Pas glop tout çà.
Je me demande s'il ne serait pas possible de réécrire la requête de manière à avoir quelque chose du genre (pas testé):

SELECT username
FROM '.USERS_TABLE.'
WHERE '.LCAS_change_case(.'username'.).' LIKE '.$_post($username).';

Quand j'aurai à nouveau du temps à y consacrer...