Discussion :

[arte61]

Hello !

Et oui, pour mon premier message j'ouvre un sujet de plus sur SfGuard ! J'en suis désolé !

Bon, avant tout, un rapide passage sur le contexte de mon projet.

J'ai pour mission de mettre en place un site qui aura pour rôle de servir de vitrine et "d'intranet" pour l'association dans laquelle je fais mon stage. Une précision au sujet de l'association, elle dépasse largement le millier de salariés, vous pouvez déjà anticiper mon envie de fournir une application au maximum 'user friendly' !
Et dans le soucis de fournir quelque chose de propre, de facilement évolutif etc, j'ai porté mon choix sur symfony ... que je ne connaissais absolument pas il y a un mois ! (et je suis encore en train de découvrir les joies et les galères de sf ).

Mon problème :
Actuellement, j'ai une table qui décrit les différents établissements et les services de l'association.
Comme vous l'avez surement compris, j'utilise pour la question des membres SfDoctrineGuard (et au passage la version 1.4 de sf). J'ai déjà commencer à travailler avec pour plusieurs fonctionnalités comme par exemple l'ajout d'informations de profil, modif des formulaire d'auth, droits sur mes pages (avec des perms du genre page_read_idDeLaPage, page_write_idDeLaPage), en somme : la base !

Avec tout ça, j'ai besoin de lier un utilisateur à un ou plusieurs etablissement/service. Ok, rien de plus simple ! Deux solutions :
1. Faire une relation n-n entre la table etablissementEtService et la table utilisateur ou le profil.
2. créer un groupe 'etablissement_idDeLetab' à la création d'un établissement et ensuite ajouter les utilisateurs dans les groupes correspondants.

Oui mais petit détail qui tue tout ! Dans chacun de ces établissements un utilisateur peut (et doit) avoir un rôle(directeur, éducateur, secrétaire, bénévole, cuisto...), et pas forcément le même dans chaque établissement !
Or j'ai appris que Symfsymf ne gère pas de lui même la possibilité de rajouter des informations (et de les exploitées) dans les tables de liaison des relations n-n. Il faut si j'ai tout compris obligatoirement passer par une table et un modèle intermédiaire en simulant le comportement n-n par deux liaisons n-1 et 1-n.

Donc n'étant pas encore super à l'aise dans l'extension et la redéfinition des plugins et des formulaires extravagants, nous avons choisi de lier directement les utilisateurs(via leur profil) aux établissements pour pouvoir présenter une premier prototype de la partie publique du site. Nous utilisons donc une table de ce type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Role:
  columns:
    etablissement_et_service_id:
      type: integer(4)
      notnull: false
    profile_id:
      type: integer
    intitule:
      type: string(255)
  relations:
    roleIdservice:
      class: etablissementEtService
      local: etablissement_et_service_id
      foreign: id
      foreignAlias: Roles
    roleIdprofile:
      class: profile
      local: profile_id
      foreign: id
      foreignAlias: Roles

Bon, nous dirons que c'est 'fonctionnel' mais sans doute pas top, surtout coté administration ! (si j'ai bien compris pour faire quelque chose plûtot propre je pourrais regarder du coté du 'ahPlugin', mais bon, ce n'est pas notre sujet).

Je pourrais continuer dans cette voie, "MAIS" il reste une dernière chose.
Il y a des ensembles d'utilisateurs qui ne sont en fait rien de plus que des "groupes" (comme le Conseil d'administration ou le Bureau par exemple) mais qui ont tout de même des rôles similaires à ceux des établissements et services (président, secrétaire, vice président, trésorier, trésorier adjoint, membre..).
Il y aurait la possibilité d'inclure cecis dans la table établissementEtService et de leur attribuer un type particulier afin de ne pas s'en servir dans les traitements etc, mais bon, pas glop comme solution ! Et je vois déjà le cas où j'aurai besoin de faire faire des choses similaires dans la partie 'intranet' !

Donc en gros : plus le choix, il faut trouver comment ajouter des "roles" ou toutes autres informations à la liaison Group-User de SfGuard !

Après de multiples recherches, impossible de trouver des informations concernant cela...
Pourtant, cela me parait aberrant que personne n'ai jamais eu besoin d'ajouter un rôle dans les groupes de sfguard sachant qu'il est l'un des plugin les plus utilisés !
Ne serait-ce le cas où il faudrait attribuer des modérateurs aux groupes par exemple (même si en écrivant je me rend compte que ça serait possible avec des permissions genre 'moderator_groupe_id', donc mauvais exemple pour le coups ! ^^).

C'est donc à partir d'ici que j'ai besoin de votre aide ! Je ne suis pas vraiment chaud pour me lancer à l'aveugle dans la redéfinition du plugin au risque d'en altérer son bon fonctionnement, surtout avec mes compétences actuelles et le temps qui m'est imparti.

-Serai-je passé à coté du tuto ou du plugin du siècle ?
- Peut-être que je suis complètement à coté de la plaque.
- Peut être alors n'ai-je pas compris une subtilité ou une astuce dans l'utilisation du plugin
- ou alors est-ce peut être tout simplement impossible ou vraiment trop galère
- est-ce que je suis obliger de faire plusieurs groupes avec le même nom et un rôle différent (etab_id_membre, etab_il président ...) ==> vraiment vraiment pas glop pour le coups ! ^^

Bref, j'espère avoir suffisamment bien exposé ma situation, mon raisonnement et ce que je cherche à faire ! En résumer : HELP ! :p
Je reste convaincu que quelqu'un en est déjà passé par là avant moi ! ^^

PS : merci à ceux qui ont eu le courage de lire le pavé ! Et merci d'avance pour vos réponses !

[PeytaWodka]

Je ne suis pas sûr d'avoir tout compris mais ce que je peux te dire :
- La relation n-1 1-n est la bonne solution (même si j'arrive toujours pas à l'appliquer mais c'est une autre histoire ^^)
- Pour l'histoire des groupes, pourquoi ne pas créer une table groupe à vous ou alors une table pour chaque groupe et la traiter comme la table etablissementEtService ?
Si c'est quelque chose que vous voulez éviter, je pense que de redéfinir la table groupeUser du plugin est possible mais vous rencontrerez surement quelques difficultés avec les formulaires. (rien d'insurmontable si vous avez réussi à régler le problème de etablissementEtService).

Ce n'est que mon point de vue et je vous conseille d'attendre d'autres conseils (notamment de Michel)

[arte61]

Déjà tu me rassure, j'ai pas tout compris de travers au sujet des relations n-n :p

Ensuite concernant la solution de créer une table par groupe, elle n'est pas viable du tout d'après moi, que ce soit en général et encore moins dans le cadre de mon appli. En effet, puisque que je laisse la possibilité aux utilisateurs d'ajouter/retirer des établissements/services la liste des groupes en sera elle aussi modifiée (au moins un groupe par établissement quoi ). Donc ajouter des tables n'est vraiment pas envisageable.

Ensuite créer une table groupe 'personnelle' en plus de celle de Sfguard, quel avantage pourrais-je en tirer mis à par le fait d'être sûr de ne pas complètement exploser le fonctionnement du plugin (mais bon, si c'est fait proprement, un petit rollback, ou un checkout et c'est réparé ^^) ?

[PeytaWodka]

Créer une table 'personnelle' te permet de t'éloigner du plugin, tu n'aura pas de dépendance fonctionnelle avec celui-ci et le jour où il y a une mise à jour (peu de chance que ça arrive) tu n'aura pas à tout revoir.
AMHA, les deux solutions sont acceptables.

[Michel Rotta]

Je vais demander un crédit particulier pour l'achat de paracétamol.

Je pense que ton principal problème ne vient pas de symfony et de ces plugins mais d'une phase d'analyse pas suffisamment approfondie.

Il faut parfois accepter de faire un saut en arrière et de reprendre la phase d'analyse.

Essaye de mettre par écris, le plus simplement possible qui doit faire quoi, quels sont les données qui doivent être gérées.

Ensuite fait un MLD et tu pourras en déduire un MPD. De là, il sera possible de commencer à discuter de l'intégration de sfGuard et de ces tables (on peut les imaginer au niveau du MLD).

Attention malgré tout au fait que sfGuard n'est pas uniquement un jeu de table, c'est aussi un objet sfGuardSecurityUser qui étend sfBasicSecurityUser et permet donc d'être compatible avec le système de récupération des droits soit par des hasCredentiel() soit par le security.yml. Si ton modèle implique que des droits seront donnés en fonction de tes relations, il est possible qu'il te faille rajouter une couche à sfGuardSecurityUser.

[arte61]

J'ai hésité avant de poster ici, mais au moins maintenant je ne regrette pas. D'après vos réponses j'ai vraiment le sentiment que l'extension du plugin de cette manière ne vous emballe pas et n'est pas une bonne solution.
Au moins ça m'évite de m'embarquer dans une mauvaise direction.

Je pense que ton principal problème ne vient pas de symfony et de ces plugins mais d'une phase d'analyse pas suffisamment approfondie.

Il faut parfois accepter de faire un saut en arrière et de reprendre la phase d'analyse.

Tu n'as malheureusement que trop raison !
En fait, comme il me semble l'avoir dit dans mon premier message, l'application aura deux fonctions : site de vitrine et intranet. Or, pour le moment seul les fonctionnalités exactes de la partie vitrine nous ont étaient spécifiées.. J'ai d'ailleurs la réunion pour les specs de la partie privée est demain matin (enfin !).
Donc jusqu'à maintenant, on a travailler avec beaucoup de "peut-être" ou "il risque d'y avoir ça" ...

donc pour le coups je pourrai commencer à me reprendre le choux demain soir mais avec de réelles données cette fois ! ^^

---------------------------------

J'ai pas trop envie de faire de plan sur la comète pour ce soir mais bon, puisque redéfinir le plug pour faire fonctionner les groupes comme je le souhaite j'ai eu une idée. Je vais vous la proposer histoire de voir si c'est mieux ou alors au contraire si je suis a 15 bornes de la solution. Au moins je l'aurait d'écrit quelque part ! :p

Je prévient ça risque de ne pas être clair ... ^^" (Michel, donne moi tes coordonnées en MP et je te fais envoyer une boite si tu veux ! xD )

Mettons qu'avec les informations que je vais avoir demain, je regroupe toutes les différentes entités de l'association (établissement, service, sous service, antenne, bureaux) dans une table un tant soit peu cohérente, on appellera cette table "etablissement" pour faire simple.
j'aurai donc toujours besoin de ce comportement qui fera qu'un utilisateur devra être dans plusieurs établissements, qu'un établissement aura plusieurs utilisateurs et qu'un utilisateur à un "role" au sein de ces établissement.
Donc jusqu'a maintenant, situation basique, trois tables [GuardUser, Role, etablissement] en relations n-1+1-n.
Ici, à moi de fouiller dans les tutos/plugin pour faire ça, j'ai d'ailleurs cru voir un topic cette semaine à ce sujet.

Tout ça c'est super pour faire de l'affichage d'information ... Mais c'est tout ? On a de jolis ensemble d'utilisateurs regroupés par services et on ne peux rien en faire d'autre ? Dommage.
Pourtant ça serait bien utile de pouvoir dire que le personnel du "service R.H." dans la table établissement peuvent avoir accé à l'interface d'ajout des utilisateurs !
ahhhh : Guard le fait déjà tout ça avec les permissions !
Mais ça veut dire recréer un groupe du nom de R.H. dans SfGuardGroups et rajouter un a un les utilisateurs dans ce nouveau groupe ? Pas glop ! :/
Ce qui pourrait être fait c'est de créer un groupe de SfGuard à la création de l'établissement et le les liers par une relation 1-1 dans un nouveau champs de la table etablissement.
Ainsi, j'imagine qu'il doit être possible de surcharger les fonctions de création/suppression des objets "role" pour automatiquement ajouter l'utilisateur aux groupes SFguard. Ainsi il serait possible d'utiliser comme habituellement les option de credentials de Guard, non ?

Vous avez réussi à suivre ? vous avez l'idée ? ^^
Est-ce que je cherche encore trop compliquer ? trop extravagant ? Est-ce mieux que la première solution ? est-ce une BONNE solution ?