Discussion :

[Jerome C.]

Bonjour,

Je suis relativement nouveau sur Symfony et un problème qui revient régulièrement est la réalisation d'une action post-enregistrement d'un objet dans la base.
Je m'explique avec un exemple, je dispose d'une table "Service" et de ma table "ServiceMembres" qui contient les membres de ce service. A la création d'un service, j'aimerai également créer un champ dans ServiceMembres afin, dans ce cas, de définir le membre créateur comme ayant les droits d'administration sur le service.

Les méthodes que j'ai utilisé pour réaliser cette action me semblent contre intuitifs et j'aimerai donc connaître la façon la plus propre de le faire.

Merci d'avance.

[Michel Rotta]

Je vais te répondre sur deux axes.

Par rapport à ta question, il y a deux approches possibles.

Soit tu veux que pour toutes création d'un objet service il y ait la création d'un objet correspondant dans la table serviceMembre. Dans ce cas là, le mieux est d'intégrer ceci dans l'objet du modèle. Ainsi, quelque soit la méthode d'ajout, tu auras toujours un serviceMembre créé. Tu peux aussi carrément l'inclure dans une transaction ce qui assure la double création, ou rien. Par contre, il faut que tu puisses retrouver les informations pour la création de l'objet serviceMembre sans avoir à passer par un form.

Si non, c'est que ta création est plus liée a la form de création qu'à la structure de la base. Dans ce cas là, le plus simple serait de créer un form, à la main, avec les informations nécessaire pour le service et le serviceMembre puis, une fois le form validé, créer les deux enregistrements, éventuellement dans une transaction.

Il y a d'autre axes d'action possible. Certain seront certainement aussi bon que les deux ici exposés (4 si on prend en compte les possibilités de traitement par transactions).


Le deuxième axe va porter sur ta structure. Si j'avais eu à gérer cela, je n'aurais pas travaillé avec les autorisation dans un enregistrement de la table serviceMembre. Si une seul personne peut avoir les autorisation, j'aurais rajouté un champ avec l'id de la personne dans l'objet service. A noter aussi qu'avec ta structure, tu considères qu'une personne peut faire partie de plusieurs service, est-ce ce que tu veux ?

Après, si plusieurs personnes doivent pouvoir avoir cette autorisation, c'est plus compliqué. D'autant qu'il est possible que certaines personnes devront, un jours où l'autre, avoir accès à un service dont il ne font pas partie ou avoir accès à plusieurs service. L'idée est alors de passer par sfGuard pour la gestion des accès et de créer, à la création d'un service, un droit "service:NomDuService" ensuite d'attribuer se droit à la personne ou à un groupe et le groupe à la personne. A l’exécution il est alors simple de vérifier si la personne à les droits sur ce service. Ceci permanentait de faire la liaison de base, sans empêcher un administrateur de rajouter autant de personnes que nécessaire.


Beaucoup de possibilités... a toi de voir ce qui colle au plus prêt de tes besoins et de revenir en discuter

[Jerome C.]

Tout d'abord merci de ta réponse, je vais tâcher de répondre aux deux axes.

Je vais te répondre sur deux axes.

Par rapport à ta question, il y a deux approches possibles.

Soit tu veux que pour toutes création d'un objet service il y ait la création d'un objet correspondant dans la table serviceMembre. Dans ce cas là, le mieux est d'intégrer ceci dans l'objet du modèle. Ainsi, quelque soit la méthode d'ajout, tu auras toujours un serviceMembre créé. Tu peux aussi carrément l'inclure dans une transaction ce qui assure la double création, ou rien. Par contre, il faut que tu puisses retrouver les informations pour la création de l'objet serviceMembre sans avoir à passer par un form.

Si non, c'est que ta création est plus liée a la form de création qu'à la structure de la base. Dans ce cas là, le plus simple serait de créer un form, à la main, avec les informations nécessaire pour le service et le serviceMembre puis, une fois le form validé, créer les deux enregistrements, éventuellement dans une transaction.

Alors, oui, je n'ai pas besoin d'informations supplémentaires lors de la création, le but étant de gérer la structure de la table serviceMembre étant simple (user_id, service_id, isAdmin). Je veux pouvoir avoir plusieurs admins pour un service et des utilisateurs membres/administrateurs de plusieurs services.

C'est donc ta première solution qui semble adaptée ici, cependant je ne suis pas très sûr de ce que "Dans ce cas là, le mieux est d'intégrer ceci dans l'objet du modèle." signifie. La réécriture de la fonction Save() ne fonctionne pas ici et il n'existe pas de fonction "afterSave()" à ma connaissance. Tu m'as perdu là désolé (:

Le deuxième axe va porter sur ta structure. Si j'avais eu à gérer cela, je n'aurais pas travaillé avec les autorisation dans un enregistrement de la table serviceMembre. Si une seul personne peut avoir les autorisation, j'aurais rajouté un champ avec l'id de la personne dans l'objet service. A noter aussi qu'avec ta structure, tu considères qu'une personne peut faire partie de plusieurs service, est-ce ce que tu veux ?

Après, si plusieurs personnes doivent pouvoir avoir cette autorisation, c'est plus compliqué. D'autant qu'il est possible que certaines personnes devront, un jours où l'autre, avoir accès à un service dont il ne font pas partie ou avoir accès à plusieurs service. L'idée est alors de passer par sfGuard pour la gestion des accès et de créer, à la création d'un service, un droit "service:NomDuService" ensuite d'attribuer se droit à la personne ou à un groupe et le groupe à la personne. A l’exécution il est alors simple de vérifier si la personne à les droits sur ce service. Ceci permanentait de faire la liaison de base, sans empêcher un administrateur de rajouter autant de personnes que nécessaire.

Alors comme expliqué, oui je veux qu'une personne puisse être membre de plusieurs services, qu'il puisse y avoir plusieurs admins etc.
Ta deuxième (quatrième ^^) solution m'intéresse beaucoup, en tout cas pour la gestion des droits d'administration. En effet, même si je réussis à utiliser cette méthode je devrais toujours ajouter l'utilisateur à la liste des membres du service lors de la création, non ?
Après si cette méthode peut me permettre de me passer d'un champ "isAdmin" et permet d'utiliser des fonctions préfaites de symfony, je suis tout ouïe. Je n'ai pas trouvé d'équivalent à l'ajout dynamique de crédentials (c'est comme ça que je comprends ta solution) dans le tutorial de Symfony alors j'apprécierai des pistes dans ce sens (:

Merci encore de ton temps, à bientôt !

[Michel Rotta]

Ok, c'est plus claire maintenant.

"Dans ce cas là, le mieux est d'intégrer ceci dans l'objet du modèle", certain ici qualifieraient cette phrase d'un : "C'est du Michel tout craché !". Et ils auraient eu raison ! Une belle phrase qui a dû surement avoir un sens un jour (une seconde) mais que plus personne ne comprend, souvent même pas son auteur...

En l' occurrence, je sais ce que je voulais dire, mais je reconnais avoir pris tellement de raccourcis que c'est indécodable. Et en plus n'est pas adapté vu les précisions que tu apportes là. L'idée était simplement de rajouter un champ "service_id" dans la table utilisateur, je suis .


Pour l'idée de gérer les "permission" dynamiquement, c'est très récent pour moi, jamais mis en oeuvre et issu de l'étude que je mêne sur Symfony 2 et plus particulièrement les ACL qui seraient, pour le coup, exactement ce que tu recherche. Mais développer aujourd'hui en Symfony 2 n'est pas encore raisonnable.

Donc on partirais sur deux systèmes indépendants :

1. La gestion des "est membre de" par l'utilisation d'une simple liaison n-n.
2. La gestion des droits sur la liste par sfGuard et automatisé pour la gestion création des "permission".

Système a priori satisfaisant mais qui, a mon avis, ne résistera pas très longtemps. J'ai un adage en analyse : "Les liaisons n-n (pure) sont la plupart du temps issues d'une mauvaise analyse". Et je pense qu'ici mon adage est vrai. En effet tu vas très vite te rendre compte qu'il n'est pas possible de savoir qui est le chef de service (je suppose que même si plusieurs personnes peuvent manager la liste il n'y a qu'un responsable), qu'il n'est pas non plus possible de savoir ce que fait la personne dans ce service, combien d'heure par semaine doit-elle y consacrer, quant y a-t-elle débuté, quant y a-t-elle ou va-t-elle arrêter d'y travailler, qui y a travaillé auparavant... et j'en oublie. Et donc qu'on ne pourra pas travailler avec une liaison n-n mais deux liaisons 1-n et n-1 ce qui n'est pas nécessairement une mauvais chose, cela complique juste un peu les formulaires et rend inutilisable les formulaire d'administration auto-généré.

PS: Tu ne trouveras pas de documentation sur l'utilisation particulière des "permissions" mais je pense qu'elle n'est pas compliquée à mettre en œuvre, juste un peu de travail dans l’objet du modèle service pour qu'il crée le droit dans la tables des "right" et le supprime à la suppression du service (mais est-il possible de supprimer un service ? quant est-il alors de l'éventuel historique ?). Pour l'attribution d'un chef de service automatiquement je suis plus septique. Mais il reste la possibilité de créer une action et un form spécifique qui demande les informations sur le service dont l'id de son chef actuel et crée les enregistrements pour tous gérer : un dans "service", un dans "serviceMembre", un dans "sf_guard_permission" (automatiquement par la création du service), un dans "sf_guard_user_permission". Le dernier sera un peu difficile a générer, il faut y réfléchir, il est possible qu'il remette en cause la création dans "permission" depuis le modèle de "service" qui ne nous laisserait pas accéder facilement au numéro (Id) de la permission créée. De l'idée mais il faut encore que tu creuses et approfondisse.

PS2: Perso je traiterais en trois temps (je suppose que les créations de service sont plus rare que les changements de chef qui eux ne pourront être facilement automatisées) création du service, attribution d'un chef et enfin attribution d'un droits. Après, tu peux toujours facturer une extension pour le faire d'un coup, mais il n'y aura plus de service nouveau avant plusieurs années et une bonne procédure devrait permettre de gérer. Et tu pourras facturer une méthode "changement du chef de service" qui, elle, a plus de chance de servir. Mais ce n'est que mon avis.