Discussion :

[Laurent001]

Bonjour,

Je vais probablement déployer un site pour un cabinet. Et potentiellement, dans le futur, à plusieurs. Je réfléchis à cette éventualité.

Que me conseillez-vous comme stratégie?

1- Un cabinet, une base?

=> Est-ce possible d'avoir des entityManagers qui partagent les mêmes entités? (la doc officielle parle d'entités distinctes).

http://symfony.com/doc/current/cookb..._managers.html

Et quid de la gestion des routes? (dû mal à réfléchir sur comment gérer ça)

2- Une base pour tous les cabinets avec jointure sur une table listant les différents cabinets

Risque: se retrouver avec une base énorme.

De plus j'ai laissé l'obligation d'avoir un email unique par user. Je tiens à ce qu'il y reste par soucis de sécurité (réinitialisation de mdp, doublon de patient).

=> si je choisis cette solution, je devrais donc virer cette contrainte et checker à chaque enregistrement de user si l'email est unique dans tel cabinet? (lourd non?)

3- Autre?

Question corrolaire:

Si je me connecte à un cabinet avec un role, disons, admin. Et que je change d'url pour aller sur un autre cabinet. Comment empêcher l'accès à ce cabinet?

[dukoid]

HUGH ! ounga ounga !

prso, je vois la chose ainsi :
je ferais une base pour tous les users de tous les cabinets.

ensuite ça dépends vraiment du volume de donnée pour un cabinet si c'est vraiment volumineux alors 1 cabinet / base est judicieux (si aucun lien n'existe entre eux)
de plus, je profiterai de dispatché les bases sur differents serveur ainsi en cas de pb, tout ne sera pas bloqué.

2) surement, on peux tout faire avec Symfony

3) pour chaque projet site cabinet tu configure un parametre dans parameters.yml (agenceRole = 'ROLE_TOULOUSE'

* à l'inscription tu affectes par exemple à user le rôle de parameter("agenceRole )
il aura donc le role de là ou il s'est inscris.

* pour le test d'accès à l'admin, tu peux faire if (parameters("agenceRole") = users.getRoleAgence()) alors ... accès autorisé
enfin voilà la philosophie !




voyons les avis d'autres personnes....

[Laurent001]

je ferais une base pour tous les users de tous les cabinets.

Ça pourrait le faire sauf que l'email doit être unique et si tu as un client qui va dans 2 cabinets...

Ou alors surcharger FOSUserbundle avec la fonction qui checke l'unicité de l'email. Pas creusé mais me parait chaud de prime abord.

3) à l'inscription tu affectes par exemple role_paris, role_toulouse
ensuite pour chaque site cabinet tu configure un parametre dans parameters.yml (agence = toulouse)

et donc comme test tu peux faire "role_"+ parameters("agence) = users.getRoleAgence()
enfin voilà la philosophie !

J'y ai pensé après coup. Vu que tu me le conseilles, ça me réconforte.

On peut p’tre même pousser le truc avec la déclaration des différentes BDD (et EM) pour écrire là où il faut.

[dukoid]

l'email sera unique parceque c'est une seule base "USER" pour tous les cabinets.
avec fosUser tu peux dire que lidentifint est soit le pseudo sot l'email et ainsi il sera unique (donc dans la base User de tous les cabinet)

c'est très simple et il y a rien à faire en réalité, c'est déjà géré par fosUser

[Laurent001]

l'email sera unique parceque c'est une seule base "USER" pour tous les cabinets.

Un user peut aller dans un cabinet avec un suivi S1. Ce même user peut aller dans un autre cabinet avec un autre suivi S2.
Il faut donc que ce même user ait 2 comptes différents (mais même email) avec leur suivi distinct.

[dukoid]

mmmmmmmmmmmmmmmmmm par principe il ne faut jamais dupliquer quoi que se soit c'est la porte ouverte à la complexité et à la gestion bidouille.
il faut trouver une solution pour qu'il y ai un seul compte et des suivis différents en fonction de son rôle d'appartenance par exemple.(comme vu plus haut)

tel user qui aura tel role aura un suivis X .... non ?

mais comme je ne connais pas ton projet et toutes les contraintes. là tu me parles de suivis....

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

de plus, sache qu'on peux faire en sorte que l'email ne soit pas unique si tu veux suivre ta solution :

1: dans config.yml dire que l'email ne sert plus d'identifiant (je ne sais plus comment voir google)
2 : modifier le modèle User

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
y\UserBundle\Entity\User:
    type: entity
    table: null
    repositoryClass: My\UserBundle\Entity\UserRepository
    attributeOverride:
      usernameCanonical:
        unique: false
        name: usernameCanonical
        column: username_canonical
        length: 255
        nullable: false
        type: string
      emailCanonical:
        unique: false      // ICI ----------------------------------------
        name: emailCanonical
        column: email_canonical
        length: 255
        nullable: false
        type: string
    fields:
        id:
          type: integer
          id: true
          generator:
              strategy: AUTO
        firstName:
          type: string
          length: 255