Bon, tout était trop beau... Je veux implementer mon Nested Set lors de la création d'un user. Mon idée était d'utiliser les events de jAuth pour "intercepter" jauth mais mauvaise idée et en plus les events arrivent après la création du user. Hors j'ai besoin de créer le nested user en premier... (insertchildof(parent_id))... Donc mes trois solutions:

• Soit faire une table du genre "user_hierarchie" qui est mise à jour à chaque event de jauth (add, update,remove), cette table serait lié via la clé primaire login... Une extension de la table dans le fond, pas vraiment top car je me retrouve avec 2 tables qui en forment en fait une seule...
• Soit ré-écrire les méthode saveuser, updateuser et removeuser de jauth... Dois je faire un module à moi dans ce cas? Comment faire simple puisque les controlleurs ne peuvent pas être overrideés...
• Écrire un plugin driver jauth db différent? jauth plugin

Idea? Merci.

la première solution sera plus perrenne dans le temps.

Par contre, pour bien répondre, il faudrait savoir quand as tu besoin des données de user_hierarchie.

laurentj a dit :
la première solution sera plus perrenne dans le temps.

Par contre, pour bien répondre, il faudrait savoir quand as tu besoin des données de user_hierarchie.

En fait j'en ai besoin pas mal tout le temps. Un professeur par exemple n'a accès que aux comptes de ses élèves et pas ceux des autres. Les élèves eux n'ont pas accès aux comptes parent (prof). Le directeur à accès aux comptes des profs et des élèves... Etc... Je me suis fait un contrôleur un peu comme le default de jauth_admin mais qui fonctionne côté client et permet à certain utilisateur (les professeurs) de créer des élèves. Pour l'instant j'ai ajouté un champ "parent_id" dans la table user mais ce n'est pas aussi pratique qu'une hiérarchie complète... Surtout qu'avec le nested je peux gérer un "ordre" facilement en plus de la hiérarchie.

Pis pour l'affichage ça me force à faire des fonction récursives (exemple: le directeur veut afficher ces enfants (prof) mais aussi les enfants de ces enfants (élèves)...) alors qu'en nested une requête suffit... Ici y'a juste trois palier, mais je vais surement ré-utiliser ça pour une hiérarchie avec une 15zaine de paliers et en plus j'aime pas les fonctions récursives (pas super pour la mémoire et les perf) :p !

Ce que je ne comprend pas, c'est quel est le rapport avec jAuth. jAuth n'en a rien à fiche de la hierarchie des users. Là, ce dont tu parles, c'est du code métier, c'est pas à jAuth de gérer ça.

Le seule truc à faire, c'est lorsqu'un nouveau user est crée ou supprimé, tu réponds aux events correspondant pour mettre à jour ta hierarchie, c'est tout. Le reste, pour l'affichage et cie, c'est géré par tes modules.

D'ailleurs, plus je relis tes trois propositions, plus je vois qu'elles ne sont pas valables, et je ne comprends pas pourquoi il faut que tu créé un "nested user" en premier. à priori, dans l'objet user que tu vas insérer, tu as le user "parent". et ce n'est qu'après l'insertion que tu calcules les bornes intervallaires, sur les users qui sont en dessous du parent. tu fais pas le calcul avant l'insertion (d'ailleurs si tu le fais, tu auras plus de requete à faire je crois).

Bref, pour moi ton problème est simple :

• tu ajoutes les champs nécessaires dans ta table de user
• tu fais le dao qui correspond (avec les mêmes méthodes que le dao d'origine)
• tu déclares ce dao dans la config jauth
• tu fais des listeners d'event sur jauth, pour mettre à jour les champs des bornes intervallaires pour les nested_set, une fois que le user est ajouté ou supprimé.

bref, tu n'a pas besoin d'une seconde table, de reecrire jauth ou je ne sais quoi.