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 ?

[Michel Rotta]

La question de base est simple. Utiliser sfGuard ou pas.

Le choix se fera sur les limitations du produit et la capacité à automatiser le transfert d'information entre ta partie applicative et le plugin.

Il reste aussi une autre possibilité, si l'on se limite à gérer les accès aux données, on peut avoir une couche parallèle à sfGuard qui, au niveau du modèle, ne retournera que les enregistrements autorisés à un utilisateur donnés. Propre ? Pas propre ? Peut importe, c'est conforme au MVC et à la sémantique de symfony et cela fonctionne.

Pour ce qui est de ton usage de sfGuard, il faut te demander comment les droits (les groupes n'ont d'intérêt que dans la mesure ou ils donnent des droits) pourront être transformés en requête. Il est simple d'automatiser la création d'un droit pour un établissement, simple aussi de l'attribuer à une personne directement, ou indirectement par un groupe. Mais est-il simple de récupérer les groupes d'un utilisateur pour transformer cette données, après filtre des droits qui ne concernent que les établissement, en une partie where prête à être intégrée dans la requête ?

Bien sur, tu pourras toujours afficher toutes les fiches et ne tester les droits qu'à la tentative d'ouverture à l'édition, en fait cela sera même indispensable pour vérifier que de "petits être intelligents" ne tentent pas de tromper ta sécurité par des URL "sauvages", mais n’afficher dans la liste que les personnes concernées par l'utilisateur sera vite un besoin crucial. Il faut y réfléchir avant de ce demander comment mettre les droits à jour.

Je suis désolé de ne pouvoir te donner une réponse ferme et définitive, en fait, à la vue des informations que tu me donnes, les trois possibilités restent viables. Un bon cahier des charges permettra certainement de s'aiguiller vers l'une ou l'autre solution.

[arte61]

Et bien Sfguard oui, rien que pour le module d'auth qui sera toujours mieux niveau performance et secu que ce que je pourrais faire...

Ensuite effectivement depuis la semaine dernière je me pose beaucoup de questions concernant les groupes et permissions :
1/ Est-ce que je dois attribuer des groupes de SfGuard aux établissements comme je l'ai déjà proposé ? ou est-ce qu'il vaut mieux que je débrouille avec la liaison déjà existante entre user et établissement ?
2/ Est-ce que dans le cas où j'attribuerai un groupe SfGuard a un etablissement il serait facil de garder la gestion des utilisateurs/groupeEtablissement automatisé et n'afficher à dans l'interface d'admin que les groupes qui ne correspondent pas à un établissement ? (et surtout où et comment changer ça! je ne sais pas vraiment à l'heure actuelle)
3/dans le même genre, est-ce qu'il faut que j'attribut une permission de Sfguard pour l'édition et l'affichage de chaque page et chaque type d'actualités ... ?
4/ et du coups est-ce facile de changer l'affichage de la liste des permissions à la création pour les trier/regrouper par type/page etc ... ?
Ce sont surtout les questions 2/ et 4/ qui me font le plus peur je crois, je n'arrive pas a me rendre compte de la difficulté de ce que je veux et surtout si c'est à ma porté...

mais bon, je vais essayer d'expliquer l'ensemble de ce que je dois faire (et en essayant aussi de ne pas trop m'étaler), peut être que vous aurez des idées :p

A - Deux Parties
Donc comme je l'ai dis il faut deux applications relativement similaire (la partie destinée au publique et la partie privée) + un espace d'administration.
Chacune de ces deux parties sera composé de pages de contenu, de listes d'actualités/billets d'informations.., d'établissements/services et de quelques modules spécifiques pas très compliquer comme la gestions des véhicules (immatriculation, modèle, état, kilométrage...) ou la gestion des livres présents dans les différents centres(pas de réservation, juste la liste pour savoir quels livres peuvent être demandés et a quels endroits).

B- Les pages de contenus
Bon bah ça rien d'extraordinaire : un titre, un contenu, une description pour aider l'admin dans la gestion , des dates..., et rouler jeunesse.
La seule chose importante à retenir, c'est qu'une page doit être modifiable par certains utilisateurs désignées spécifiquement pour entretenir telle ou telle page. Je m'explique, ce n'est pas un groupe d'utilisateurs (genre des modos) qui sont désigner pour gérer l'ensemble des pages du site, mais par exemple la page 'A' sera modifiable par les utilisateurs toto, tutu et tata alors que la page B sera modifiable par tata, momo et Robert !
Et pareil pour l'affichage, de manière général il n'y aura pas de restriction pour l'affichage des pages de contenu sauf comme dit le client : "peut être dans un cas exceptionnel on voudrait qu'il n'y ai que tel ou tel type de personne qui voit cette page"(genre les ressources humaines qui voient une pages que d'autres ne voient pas)
(et biensure on doit pouvoir ajouter autant de pages qu'on veut depuis l'admin ^^ )

c - les établissements et services
Donc ici, gros morceau ! On doit pouvoir avoir la liste des différents établissements et services. pour chaque établissement/service il y a différentes informations et pages de contenu comme :
- une page de description de l'établissement
- une page de contact (juste du contenu qui dis quels numéros appelés etc etc, rien de plus), chaque établissement donnera les informations qu'il veut ici.
- des actualités propres à l'établissement (biensure, n'importe qui ne pourra pas ajouter d'actualités, comme pour les pages quoi)
- une carte style google Map (ça j'ai déjà fait, j'ai presque réussi a mettre toutes les options que je souhaite, il ne me reste plus qu'a regarder comment permettre de calculer un itinéraire depuis cette page directement)
- une page 'equipe' : donc du contenu qui contiendra notamment un shema de l'organisation de l'établissement en interne et qui surtout devra lister ses membres et LES ROLES qu'ils jouent au sein de cet établissement. (comme je l'ai dis, un utilisateur peur faire parti de plusieurs établissements/services avec des roles différents)
- chaque établissement/service aura les mêmes pages, pas de rajout spécifique pour seulement un établissement ou deux.

pour faire ça actuellement j'ai créer plusieurs pages de contenus pour chaque 'type de page' des établissement (description, équipe, rapport moral..) et chaque établissement à des champs d'information sur l'adresse, le CP, la ville etc...

donc ici, petite interrogation, faut-il seulement attribuer une seule fois une personne ayant les droit de modifier toutes les pages concernant l'établissement, donc peut être faire une permission juste pour l'établissement, ou alors, garder le fonctionnement normal qui sera fait pour les droits des pages 'simples', a voir au plus simple en vu de ce que qui sera choisi pour faire les droits/groupes.

D - les actualités
donc rien d'innovant : titre, contenu, date, auteur...
mais comme je l'ai dis, y'a différents "types" d'actualités : au moins un par établissement/service.
Mais y'a aussi des types en extra genre ce qu'on appel "les billet du président", des actualité d'information générale, des actualités d'information sur le monde juridique etc...
donc ici, forcément, une table type_actualité et je pense, des droit pour l'ajout d'actualités d'un certain type.


E - autres modules
bon ensuite y'a des modules un peu plus spécifiques mais qui vont réutiliser les 'composant' du dessus !
- page d'accueil, donc une page de contenu standard décorée par la liste des dernières actualités (tout type confondu) et un bando défilant contenant les logos des partenaires, rien de compliquer.
- une page trombi, qui présentera les faces de toutes les hautes têtes de l'assos (donc un groupe spécial et ça ira bien pour ça je pense^^ )
- dans le même genre, une page qui présente les faces des gens constituant les différents bureaux administratifs
- une page de contact qui regroupe toutes les pages de contenu contenant les informations de chaque établissement/service (et on colle tout ça dans un "accordéon" Jquery pour pas avoir une page de 15kilomètres ^^
- un truc pour la gestion des bouquin, des véhicules etc ...
- que des trucs plutot banal en fait !

et pour finir :
F- Utilisateurs
bon pour les utilisateur, ça pas d'inscription libre, ça ne sera que les gens du service R.H. qui seront chargés de faire les inscriptions des salariés de l'assos !
un utilisateur pourra mettre a jour lui même les informations de son profil comme sa photo, son mail et son adresse.. encore une fois rien d'extra ordinaire, j'ai vu passé masse de tutos à ce sujet en plus je crois.
donc la création d'un utilisateur :
- choix du login/mdp(et génération automatique plus tard ^^ )
- remplissage des information de profil (bon bah go tuto bête et méchant.. )
- et .. ah bah c'est là que ça se gatte en fait ! ^^
ce que je veux c'est à la création du l'utilisateur pouvoir le colé dans différents etablissements/services et lui attribuer son role dans chacun d'eux
- ensuite pouvoir le collé dans des groupes 'spéciaux' qui n'ont rien a voir avec les établissement service (comme pour dire que il est dans le groupe modérateur si on ajoute la possibilité de faire des commentaires sur les actualités, ou dire qu'il est dans le groupe du conseil d'administration, ou X-trucs qu'on pourrait rajouter)
- et pour finir : je voudrait pouvoir attribuer des permissions simplement à un utilisateur en particulier, notamment, pour l'histoire de modification des pages ou j'aimerai que ça soit trié par page en fait non, plus j'y pense, plus que me dis que les droits rares comme la modification d'une page, d'un établissement ou l'ajout d'actualités devront être attribués par l'admin depuis leur modules respectifs...
Du coups, je voudrais juste afficher les droits spéciaux qui n'ont rien a voir avec les pages / établissement actualités ( peut être que c'est les effets de la fatigue mais sur l'instant là, ça me parait plus logique ! )

pioufff, je crois ne rien avoir oublier d'important ... mais rien que le fait de le réécrire une fois de plus ça m'a remis bien les idées d'écaire.
et du coups, mes deux dernières phrases me font encore plus réfléchir à ce que j'ai écris au début du message et aux doutes de michel quand à quelle utilisation faire de Sfguard dans mon cas.

Des idées ?



sinon, j'ai un gros soucis d'ordre technique qui reste dans le sujet du topic concernant SfGuard et ahDoctrineEasyEmbedRelations, pas moyen de faire fonctionner ça correctement dans le formulaire de Sfguard (ou de profil) alors que n'importe ou ailleur c'est les doigts dans le nez !
mais bon, je vais pas surcharger ce message qui est déja bien fourni, et vu l'heure, je referai un poste demain matin au bureau !

[arte61]

hello !
bon comme je l'ai dis hier soir, j'ai un sushi avec les formulaires de SfGuard.
9a survient au moment ou j'essaie de faire ma liaison entre un utilisateur et un établissement en attribuant un "Role" à cette liaison).
Donc comme je l'ai expliquer dans les messages précédent, j'utilise pour ça trois tables liées en N1+1N.

pour faire ça, j'ai installé le plugin de ahDoctrineEasyEmberedRelations, je l'ai testé sur des relations n-1 standard et aucun soucis tout fonctionne nickel chrome (ajout multiple, suppression, Maj...)


Mais pour faire ma liaison tri-table (ça se dit ? ).. pas moyen !
Une petite précision : la table SfGuardUser est déjà étendu par une table "Profile".
Nous avons tenter différents cas de figure :
1/ lier la table intermédiaire "Role" à SfGuardUser, c'est le fonctionnement de base que je souhaitais.
--> résultat : aucun, y'a juste le formulaire embarqué de profile, pas celui des "roles"
2/ lier Role à profile (3niveaux de formulaire embarquer c'est pas top je pense, si ? )
--> cette fois on a un résultat, mais on a pas les actions attendues, l'ajout multiple ne fonctionne pas, les formulaires vident sont ajouter, et l'option delete n'a aucun effet
3/ on a essayer avec une table Role dont la clef primaire est un Id avec deux foreignK et avec une table role qui possède deux clefs primaires directement.

voila les extrait de code que la solution 2/ (bon, le code est le résultat de 50 tests, donc oui il est pas super propre tout de suite ^^' )

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
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
Profile:
  columns:
    sf_guard_user_id: 
      type: integer
    nom: 
      type: string(255)
    prenom:
      type: string(255)
    rue:
      type: string(255)
    code_postale:
      type: string(5)
    ville:
      type: string(255)
    numero_portable:
      type: string(10)
    numero_poste:
      type: string(10)
    photo:
      type: string(255)
  relations:
    sfGuardUser:
      class:       sfGuardUser
      foreignType: one
      onDelete:  cascade
 
EtablissementEtService:
  actAs:
    NestedSet:
      hasManyRoots: true
      rootColumnName: root_id
  columns:
    id:
      type: integer(4)
      primary: true
      unique: true
      notnull: true
      autoincrement: true
    token:
      type: string(255)
    name:
      type: string(55)
    type:
      type: enum
      values: [Etablissement, Service, Activité, Antenne]
      default: [Etablissement]
    adress: string(255)
    cp: string(55)
    ville: string(55)
 
Role:
  columns:
    etablissement_et_service_id:
      type: integer
      notnull: true
    profile_id:
      type: integer
      notnull: true
    intitule:
      type: string(255)
  relations:
    roleIdservice:
      class: etablissementEtService
      local: etablissement_et_service_id
      foreign: id
      onDelete: cascade
      foreignAlias: Roles
    roleProfile:
      class: Profile
      local: profile_id
      foreign: id
      onDelete: cascade
      foreignAlias: Roles

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
class sfGuardUserAdminForm extends BasesfGuardUserAdminForm
{
  /**
   * @see sfForm
   */
      public function configure() {
 
           parent::configure();
 
            // .... validators ...             
 
             $this->widgetSchema['permissions_list'] = new sfWidgetFormDoctrineChoice(array('model' => 'sfGuardPermission', 'expanded' => true, 'multiple' => true));
 
           $profileForm = new ProfileForm($this->object->Profile);
           unset($profileForm['id'], $profileForm['sf_guard_user_id']);
           $this->embedForm('Profile', $profileForm); 
        } 
}

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
21
22
23
24
25
class ProfileForm extends BaseProfileForm
{
  public function configure()
  {
      $this->widgetSchema['photo'] = new sfWidgetFormInputFile(array(
                  'label' => 'photo utilisateur',
                ));
 
       $this->validatorSchema['photo'] = new sfValidatorFile(array(
          'required'   => false,
          'path'       => sfConfig::get('sf_upload_dir').'/photo',
          'mime_types' => 'web_images',
        ));
 
        $this->embedRelations(array(
             'Roles' => array(
             'considerNewFormEmptyFields' => array('intitule', 'etablisement_et_service'),
             'multipleNewForms'              => true,
             'newFormsInitialCount'          => 1,
             'newRelationButtonLabel'        => '+',
             'formClassArgs'                 => array(array('ah_add_delete_checkbox' => true)),
             )
             )); 
  }
}

Voila, y a-t-il quelque chose de particulier à faire pour utiliser les formulaires embarqués correctement avec SfGuardUser et en cumulant tout ça avec le profile ??
j'imagine que pour la solution que je viens de montrer c'est le fait d'avoir 3 niveaux de formulaire qui n'est pas apprécié mais sans certitude.
Dans l'immédiat je vais essayer de supprimer les profiles pour vérifier qu'il n'y a pas conflit entre les formulaires embarqués de role et de profil lorsqu'on lie les roles à SFGuard directement.. mais bon, j'en doute =/

[Michel Rotta]

Après trois jours de lecture ... Plus un jour pour le deuxième message

Pas plus à dire que dans mon précédant message.
Pour l'utilisation de sfGuard ou pas, je ne suis pas plus fixé. Je pense que l'affichage de liste par accès va être difficile. Il faudra envisager, si tu veux des liste de ce qui est modifiable, de transférer une partie de gestion des droits ailleurs (soit un champ avec l'id de la personne dans établissement, soit une (ou deux pour les groupes) tables qui lierons les user (et les groupes) aux établissement, plus simple à manipuler dans un DQL.

Pour les pages de contenu, on peut envisager de créer des droits, mais il ne faut pas non plus envahir la table des droits par une foultitude de droits (du genre un par page, qui rendrait à terme la lecture et l'utilisation de la table impossible). Dans ce cas, un système annexe, dans le style de celui précédant devrait être envisagé.

On peut aussi envisager de factoriser ce système de droit pour n'avoir qu'un jeu de tables pour les établissements, les service et les pages. A étudier.

Dans ton schéma, tu aurais intérêt à ce que la table profil soit héritière de la table sfGuardUser. Ceci devrais simplifier ton schéma et faire disparaitre un paquet de questions que tu te poses. Accessoirement, tu as des champs qui font double emploi, nom et prénom en font partie.

Pour les relations, je ne peux juger, il manque par trop de table pour vérifier. Celle qui apparaissent semble correcte.

Je ne mettrais pas la définition des clefs (id) et laisserait doctrine le faire directement.

Évite comme la peste les champs enum. Un champ integer et une table rendue par ton modèle sont largement plus souple et s'intègre mieux dans le fonctionnement de symfony.

[arte61]

ok, j'ai fais ça pour les droits, un relation n-n entre user et page, la même chose avec les actualités

Voici le dernier shema en date :

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
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
---
detect_relations: true
options:
  collate: utf8_unicode_ci
  charset: utf8
  type: InnoDB
 
 
Profile:
  columns:
    sf_guard_user_id: 
      type: integer
    adresse:
      type: string(255)
    code_postale:
      type: string(5)
    ville:
      type: string(255)
    numero_portable:
      type: string(10)
    numero_tel:
      type: string(10)
    photo:
      type: string(255)
    date_de_naissance:
      type: date
    lieu_de_naissance:
      type: string(255)
  relations:
    sfGuardUser:
      class:       sfGuardUser
      foreignType: one
      onDelete:  cascade
 
Module:
  columns:
    token:
      type: string(255)
    description:
      type: string(255)
    route:
      type: string(255)
 
Menu:
  actAs:
    NestedSet:
      hasManyRoots: true
      rootColumnName: root_id
  columns:
    name:
      type: string(255)
    is_activated:
      type: boolean
      default: true
    module_id:
      type: integer(4)
      notnull: true
    url:
      type: string(255)
      notnull: false
    page_id:
      type: integer
      notnull: false
  relations:
    Type:
      class: Module
      local: module_id
      foreign: id
      foreignAlias: Categories
      onDelete: cascade
    Page:  { local: page_id, foreign: id }
 
Page:
  actAs: { Timestampable: ~ }
  columns:
    token:
      type: string(255)
    title:
      type: string(55)
    content:
      type: blob(65535)
    short_description:
      type: string(255)
    is_deletable:
      type: boolean
  relations:
    Category:
      class: Category
      local: Category_id
      foreign: id
      foreignAlias: Pages
      onDelete: cascade
 
# lien n-n pour la modification des pages
PageSfGuardUser:
  columns:
    page_id:  { type: integer, primary: true }
    sf_guard_user_id: { type: integer, primary: true }
  relations:
    Page:  { onDelete: CASCADE, local: page_id, foreign: id }
    SfGuardUser: { onDelete: CASCADE, local: sf_guard_user_id, foreign: id }
 
TypeActualite:
  columns:
    name:
      type: string(255)
    description:
      type: string(255)
 
Actualite:
  actAs: [Timestampable]
  columns:
    token:
      type: string(255)
    title:
     type: string(155)
    content: 
     type: string(255) 
    is_public:
      type: boolean
    is_publish:
      type: boolean
    content:
      type: blob(65535)
    type_actualite_id:
      type: integer(4)
      notnull: true
    author_id:
       type: integer
  relations:
    typeid:
      class: TypeActualite
      local: type_actualite_id
      foreign: id
      foreignAlias: Actualites
      onDelete: cascade
    sfGuardUser:
      class: sfGuardUser
      local: author_id
      foreign: id
      foreignAlias: Actualites
 
# lien n-n pour la creation d'actualites dans un type
TypeActualiteSfGuardUser:
  columns:
    type_id:  { type: integer, primary: true }
    sf_guard_user_id: { type: integer, primary: true }
  relations:
    TypeActualite:  { onDelete: CASCADE, local: type_id, foreign: id }
    SfGuardUser: { onDelete: CASCADE, local: sf_guard_user_id, foreign: id }
 
# exemple : etablissement, service, bureau, antenne, commission...
TypeEtablissement:
  columns:
    name:
      type: string(255)
 
Pole:
  columns:
    name:
      type: string(255)
    color:
      type: string(255)
 
Etablissement:
  actAs:
    NestedSet:
      hasManyRoots: true
      rootColumnName: root_id
  columns:
    token:
      type: string(255)
    name:
      type: string(55)
    type_etablissement_id:
      type: integer(4)
    pole_id:
      type: integer(4)
    adress: string(255)
    cp: string(55)
    ville: string(55)
    page_presentation_id: {type: integer}
    page_contact_id: {type: integer}
    page_equipe_id: {type: integer}
    page_projet_id: {type: integer}
    page_outils_loi_id: {type: integer}
    page_actions_id: {type: integer}
    page_evaluation_interne_id: {type: integer}
    page_tableau_debord_id: {type: integer}
    type_actualite_id: {type: integer}
  relations:
    typeId:
      class: TypeEtablissement
      local: type_etablissement_id
      foreign: id
      onDelete: cascade
      foreignAlias: Etablissements
    pagePresentationId:  {class: Page, local: page_presentation_id, foreign: id, foreignAlias: Etablissements}
    pagecontactId:  {class: Page, local: page_contact_id, foreign: id, foreignAlias: Etablissements}
    pageEquipeId:  {class: Page, local: page_equipe_id, foreign: id, foreignAlias: Etablissements}
    pageProjetId:  {class: Page, local: page_projet_id, foreign: id, foreignAlias: Etablissements}
    pageOutilsDeLoiId:  {class: Page, local: page_outils_loi_id, foreign: id, foreignAlias: Etablissements}
    pageActionsId:  {class: Page, local: page_actions_id, foreign: id, foreignAlias: Etablissements}
    pageEvaluationInterneId:  {class: Page, local: page_evaluation_interne_id, foreign: id, foreignAlias: Etablissements}
    pageTableauDeBordId:  {class: Page, local: page_tableau_debord_id, foreign: id, foreignAlias: Etablissements}
    typeActualiteId:  {class: TypeActualite, local: type_actualite_id, foreign: id, foreignAlias: Etablissements}
 
EtablissementUserRole:
  columns:
    etablissement_id:
      type: integer
      notnull: true
    sf_guard_user_id:
      type: integer
      notnull: true
    intitule_role:
      type: string(255)
  relations:
    roleIdetablissement:
      class: Etablissement
      local: etablissement_id
      foreign: id
      onDelete: cascade
      foreignAlias: Roles
    roleUser:
      class: sfGuardUser
      local: sf_guard_user_id
      foreign: id
      foreignAlias: Roles
      onDelete: cascade   
 
Vehicule:
  columns:
    immatriculation:
      type: string(255)
      notnull: true
    type:
      type: string(255)
    marque:
      type: string(255)
    modele:
      type: string(255)
    kilometrage:
      type: integer
    observation:
      type: string(255)
    etablissement_id:
      type: integer(4)
  relations:
    etablissementId:
      class: Etablissement
      local: etablissement_id
      foreign: id
      foreignAlias: Vehicules
 
Ouvrage:
  columns:
    isbn:
      type: string(255)
      notnull: true
    titre:
      type: string(255)
    resume:
      type: string(255)
    observation:
      type: string(255)
    etablissement_id:
      type: integer(4)
  relations:
    etablissementId:
      class: Etablissement
      local: etablissement_id
      foreign: id
      foreignAlias: Ouvrages
 
Partenaire:
  columns:
    nom: 
      type: string(255)
    logo:
      type: string(255)
    type:
      type: enum
      values: [financeur structurel, collaborateur ponctuel]
      default: [financeur structurel]
    lien:
      type: string(255)
 
OffresEmploi:
  actAs: [Timestampable]
  columns:
    intitule:
      type: string(255)
    contrat:
      type: enum
      values: [CDI, CDD, Apprentissage]
      default: [CDI]
    contratType:
      type: enum
      values: [Temps plein, Temps partiel]
      default: [temps plein]
    contratTime:
      type: string(255)
      default: indertermine
    lieu:
      type: string(255)
    content:
      type: blob(65535)
    active:
      type: boolean
    token:
      type: string(255)
    etablissement_id:
      type: integer(4)
      notnull: false
    expired_at: 
      type: timestamp
      notnull: true 
  relations:
    offreIdetab:
      class: Etablissement
      local: etablissement_id
      foreign: id
      foreignAlias: OffreEmplois
      onDelete: cascade

je me demande par contre si j'ai fait les relations n-n de la meilleure façon qui soit.

sinon, le problème de la relation n-1+1-n avec sfguard et adDoctrineEasyEmbededRelations est résolu...
en fait aucun soucis d'ordre technique, tout fonctionne à la perfection
le problème venait du fait que mon collègue s'était occupé de la création du 'profil' pour étendre SfGuardUser et avait suivi ce ce tuto.
La seule chose c'est qu'il avait modifier directement le code du plugin de Sfguard ... et qu'il avait "oublier" .. (oui il s'est fait bénir ^^ )

PS : pour une fois j'ai un message presque court ! ^^

[PeytaWodka]

Si tu pouvais partager le code que tu as fait pour la relation n-1 1-n, ca m'aiderait beaucoup ?!

[Michel Rotta]

Je ne suis pas convaincu par l'usage d'un detect_relations: true