Discussion :

[DanaKil]

Bonjour,

Via FosUserBundle, j'aimerais créer plusieurs "profils" utilisateur, c'est-à-dire pouvoir gérer des types d'utilisateurs qui n'utilisent pas la même classe (et donc pas les même champs). Je suppose qu'il s'agit alors d'avoir une table principale qui contient les champs nécessaires à la connexion (login, mot de passe...) puis deux (ou plus) tables avec des champs spécifiques qui seront agrégés à la table principale.

Je crois que dans la version 1.4 de symfony, il existait des "profiles" qui permettaient de faire cela. Existe-t-il quelque chose de similaire dans FosUserBundle ? Il y a bien une histoire de "Groups" dans la doc mais je ne comprends pas trop à quoi ils servent.

Merci

[DanaKil]

Je réponds moi-même à ma question, mais sans réelle solution (pour l'instant !).

Quelqu'un posait la même question ici ("FOSUserBundle multiple user types ?!") :
http://groups.google.com/group/symfo...lnk=raot&pli=1

Une réponse datée du 22 août indique que quelqu'un a une solution. Cela a nécessité un patch qui a été accepté sur le FosUserBundle. En gros, il utilise deux user managers et deux firewall... Par contre la démarche est loin d'être détaillée...

Le fait d'avoir deux types d'utilisateurs complètement différents me paraît être quelque chose d'assez courant et je m'étonne qu'il n'y ai pas de solution "prête-à-l'emploi"... Je remonte donc le post en espérant que d'autres personnes seront intéressée

[dourouc05]

Il y a bien une histoire de "Groups" dans la doc mais je ne comprends pas trop à quoi ils servent.

Un groupe permet de donner une série de droits.

Le fait d'avoir deux types d'utilisateurs complètement différents me paraît être quelque chose d'assez courant et je m'étonne qu'il n'y ai pas de solution "prête-à-l'emploi"...

Euh... du tout. Je n'en vois pas du tout l'utilité, à vrai dire ! Tu peux avoir des visiteurs et des administrateurs, mais ils seront distingués par leurs droits (donc groupes). Donc l'existant suffit largement.

[Philoulheinz]

Merci DanaKil!

J'ai également le même problème : des types d'utilisateurs avec des profils différents.

je vais aller voir le lien que tu donnes.

[DanaKil]

@dourouc05

Merci pour ta réponse mais elle ne fait pas avancer le problème ... L'objectif n'est pas de restreindre l'accès à certaines pages/fonctionnalités mais de gérer des types d'utilisateurs avec des profils complètements différents, c'est-à-dire des colonnes différentes dans leur table au final (et je ne parle pas de seulement un champ ou deux que je pourrais éventuellement laisser non renseigné, mais de tables vraiment différentes).

L'idéal serait donc d'avoir une table de base avec quelques champs communs (login, mdp...) et un flag identifiant le type de l'utilisateur, puis des tables avec les champs additionnels pour chaque type que l'on pourrait agréger à la table de base en fonction du type (ou une autre méthode similaire...).

[dourouc05]

Je ne vois toujours pas le besoin là-derrière, mais bon . Tu aurais un exemple pratique ?

Tu peux envisager de donner un « droit » à chaque utilisateur, qui t'indiquera le type d'utilisateur dont il s'agit. Tu sauras donc dans quelle table aller chercher les infos nécessaires. Il me semble que c'est une solution assez simple, mais je n'ai pas testé. Tu peux donner les droits directement à l'utilisateur ou en l'associant à un groupe (vu que je suppose qu'il y aura des séries de droits différents).

[david0887]

des profils différents comme par exemple:

- des utilisateurs "lambda" avec des rôles membres, admin, modérateur, etc.
- des utilisateurs "entreprise" avec un rôle entreprise et où l'on aurait besoin de gérer des info supplémentaires (n° siret, dirigeant, ...)

c'est ça ??

[DanaKil]

des profils différents comme par exemple:

- des utilisateurs "lambda" avec des rôles membres, admin, modérateur, etc.
- des utilisateurs "entreprise" avec un rôle entreprise et où l'on aurait besoin de gérer des info supplémentaires (n° siret, dirigeant, ...)

c'est ça ??

C'est ça oui. Ce n'est pas vraiment une question de droit, le truc c'est que certains utilisateurs vont être par exemple des commerciaux, avec de nombreux champs spécifiques à leur fonction, d'autres vont être de simple visiteurs du site avec très peu de champs nécessaires, d'autres vont être des administrateurs avec là encore de nombreux champs encore différents des commerciaux...

Je ne parle pas ici d'un simple site de blog ou un petit administrateur avec quelques droits particuliers suffit, il s'agit plus d'une grosse webapp avec un backend complexe (nombreux types d'utilisateurs...), et un front plus simple avec des utilisateurs plus simples qui peuvent passer des commandes etc.

Bien sûr je pourrais faire une grosse table fourre-tout mais de nombreux champs seraient laissés vides la plupart du temps et ce n'est pas très propre...

Au final ça serait quand même parfait si je pouvais récupérer dans mon objet user tous ces champs spécifiques qui seraient simplement "ajoutés" à la table de base "login/mdp..." une fois la connexion effectuée.

Je ne connais pas bien symfony 1 (ni le 2 d'ailleurs ) mais je crois bien que cette fonctionnalité était présente via les "profiles" de sfGuard.

Peut-être que c'est moi qui ne voit pas une méthode simple qui peut vous paraître évidente cela dit, mais en tout cas ça ne me parait pas "inutile" du tout...

[zakarisz_ghent]

J'ai une solution (pas très propre, je vous l'accorde) à proposer.
Bien sûr ça dépend du nombre de types d'utilisateurs que tu vas avoir à manipuler mais tu pourrais créer dans ta classe user des champs profileCommercial, profileAdmin, etc qui seraient liés (association one-to-one) aux tables correspondantes et contenant tes champs spécifiques.

L'avantage, c'est qu'un même utilisateur peut cumuler plusieurs types (je ne sais pas si ça te serait utile).
Mais c'est également un inconvénient si tu as de nombreux types d'utilisateurs et qu'un même utilisateur ne peut avoir qu'un seul type : tu vas te retrouver avec le problème des nombreux champs vides.

Du coup, pour tester le type d'utilisateur il suffit de vérifier quels champs de profile sont renseignés ou non.

D'ailleurs en réfléchissant, je me dis que cette solution de permet de limiter la dispersion des informations : si tu as des champs communs à plusieurs types d'utilisateurs, tu peux les mettre dans une table à part (ex: ProfileCommercialGenerique) et mettre les champs plus spécifiques dans d'autres (ex: ProfileCommercialTerrain et ProfileCommercialTelephone)

Je ne sais pas si je suis clair dans mes explications ?

[DanaKil]

J'ai une solution (pas très propre, je vous l'accorde) à proposer.....

Merci pour ta réponse. Je pensais aussi à quelque chose dans ce style mais ce n'est pas très "efficace" et on est encore loin de la solution plus élégante des "profiles" de SfGuardUser (http://trac.symfony-project.org/wiki...aDocumentation)

L'idéal aurait été d'avoir un simple champ dans la table User pour spécifier de quel type ("profil") est l'utilisateur, puis de pouvoir utiliser un

Code :

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

$this->getUser()->getProfile()->getSpecificField()

comme dans SfGuardUser.

Je vais continuer à chercher quand j'aurai le temps de m'y remettre...

[legabz]

J'ai le même besoin et je n'ai pas trouvé de solution... y a t-il du nouveau à ce sujet ?

[gladiateurking]

L'idéal aurait été d'avoir un simple champ dans la table User pour spécifier de quel type ("profil") est l'utilisateur, puis de pouvoir utiliser un

Oui C'est une solution pour utiliser des profils différent mais je propose une autre solution: Tu peux avoir plusieurs formulaires pour la même entité, et ainsi forcer tous les champs pour les users de profilc A, et seulement qq uns pour les users de profil B. Finalement tu as 1 seul type d'utilisateur.

[ascito]

Bon je vous accorde je sais pas si c'est possible sur sinfo, mais l'idée est :

une table user
une table order
une table detail

dans la table user : S2 ; dans order S1,S2 ; dans detail (id , type , detail )

S2 , 'add' , '{du json}'

dans la table detail, quoi qu'il arrive tu peu passer une clé étrangère, et des infos

du coup dans la 3 colonnes le JSON est primordiale

[arnooo999]

Bonjour,

Doctrine peut gérer différentes stratégie d'héritage:
http://docs.doctrine-project.org/pro...e-mapping.html

Cela peut sans doute se combiner avec le FOSUserBundle...

[senol1]

Je sais pas à quand date votre publication mais je croix que ce bundle est fait pour vous. : https://github.com/PUGX/PUGXMultiUserBundle

Il utilise fosuserbundle.

++

[Adn09]

Bonjour ,

j'ai un probleme en utilisant FOSuserBundle ( un probleme d'identification ) quand jessaye de m'identifier j'ai une erreur qui s'affiche (La requête d'authentification n'a pas pu être executée à cause d'un problème système.),
avant j'arrivais a m'identifier mais maintenant j'arrive plus , cela apres avoir ajouter d'autre entités facture et reclamation .