FOSUserBundle avec plusieurs type d'utilisateurs

a marqué ce sujet comme résolu.

Salut à tous,

Toujours dans le cadre de mon premier projet avec Symfony, je reviens vers vous avec un problème concernant le FOSUserBundle.

Pour une application je gère des clients, des administrateurs et des chauffeurs. Dans le fonctionnement logique de la chose, le client a accès à son propre espace, les administrateurs aux urls cachés derrière /admin et les chauffeurs aux urls cachés derrière /chauffeur (c’est un exemple).

Jusqu’ici pas de soucis, je peux jouer avec les rôles si j’ai bien le saisi.

Mais dans ma base de donnée mes clients ne vont pas avoir les mêmes champs que mes administrateurs ou mes chauffeurs. Encore un exemple : client(id, code_client, responsable, telephone), admin(id, identifiant, email, password) et chauffeur(id, identifiant, telephone, type, password)

Certains champs sont en communs mais d’autres sont propres à chaque type d’utilisateur (j’ai simplifié les champs mais il y’en a plus).

Au début je pensais pouvoir créer une entité "User" et ensuite en créer d’autres du genre "Client", "Admin" et "Chauffeur" qui viendraient étendre cette entité User mais apparemment c’est impossible.

Comment faire ce genre de chose alors ?

Est-il propre d’avoir juste une entité User qui va contenir tous les champs de mes 3 types d’utilisateurs et d’en laisser des NULL pour ceux qui n’ont pas besoin de ces informations ?

Par ailleurs une autre question qui va de paire, en fonction de ça est-il possible d’avoir 3 formulaire de connexion différents ?

J’ai fait beaucoup de recherches mais soit je comprends pas exactement, soit j’ai l’impression que c’est impossible. Pourtant la plupart des sites utilisent bien des comptes utilisateurs sur leur site et des comptes administrateur pour un back-office non ?

Si quelqu’un peut m’éclairer car j’avoue que je suis perdu avec ce FOSUserBundle, merci d’avance :)

Salut !

Il est possible de créer une entité User et de l’étendre avec d’autres entités, Doctrine propose des mécanismes d’héritage. Maintenant, je ne les ai jamais testés avec différents types d’utilisateur, mais à froid je ne pense pas que ça pose problème, sauf éventuellement au niveau de la gestion des sessions peut-être.
Du coup, un des mécanismes implique de mettre toutes les entités dans la même table. Donc évidemment, les champs ne sont remplis que pour l’entité qui les possède.

Pour le coup, vu que c’est une seule entité User, plus vraiment besoin de plusieurs formulaires vu que c’est le même mécanisme d’authentification (on tape dans la table des utilisateurs, quels qu’ils soient), mais uniquement de rediriger vers le bon tableau de bord en fonction du rôle. Tant mieux, parce que plusieurs formulaires de connexion, c’est un coup à faire se mélanger les pinceaux aux utilisateurs…

+0 -0

Salut,

Ce que tu cherches à faire s’appelle l’inerithance mapping. Ymox t’a donné le bon lien.

L’héritage de mapping fonctionne, mais attention. Premièrement, niveau performance ce n’est pas forcément top. Deuxièmement, certains bundles (ou certaines fonctionnalités de certains bundles) ne fonctionnent pas lorsqu’une entité est en inheritance. C’est le cas par exemple du softDeleteable de StofDoctrineExtensionsBundle. J’ai passé des dizaines d’heures à devoir supprimer une inheritance mapping sur un projet au boulot (bon c’était très très particulier, normalement c’est plus rapide).

Mon point de vue là-dessus, c’est que ça fonctionne, mais pas avec tout. Et comme il est facile au final de faire autrement, je préfère faire autrement. Dans ton cas, en créant par exemple une table par type d’utilisateur (user__admin, user__truc, etc.) avec une relation sur l’entité User. Ainsi ta table User n’est pas pleine de champs inutiles, et tu peux faire ce que tu souhaites.

Concernant la question sur le formulaire de connexion, tu peux en avoir autant que tu le désires. Mais ce n’est pas forcément utile : peu importe que ce soit un admin ou un simple utilisateur qui se connecte, l’action sera de se connecter. L’exception est éventuellement pour mettre une page de login dans l’espace d’admin (admin/login).

+1 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte