Discussion :

[van___fanel]

Bonjour,

je ne sais pas si ce sujet à plus sa place ici ou sur le forum PHP Général. Merci de le déplacer si besoin.

Je travaille sur un projet, qui demande une gestion des droits très complexe. J'ai déjà développé de tels systèmes, mais jamais aussi complexe que celui que je dois faire actuellement.

Description :

Il s'agit d'un extranet, pour une association, que l'on va appeler A. A gère de nombreuses entités, que l'on va nommer B. Tous les B sont indépendants les uns des autres, leur seul point commun est d'être membre/client de A.

Les membres de chaque entité B sont classés en niveaux : Admin, membre, ancien membre.
Les membre de A sont classés en niveaux : Admin, membre. A est divisé en plusieurs pôles (Administration, Finances, Communication). Un membre de A peut cumuler les pôles, ou être à la fois Admin, et membre d'un pôle.

En se connectant sur l'extranet, les membres d'une entité B ont accès à la gestion de leur entité, et de leur compte perso. Et des droits différents sur l'ensemble des infos de leur entité, en fonction de leur niveau :
- Un admin aura des droits en lecture/écriture sur les informations de l'entité
- Un simple membre aura seulement les droits en lecture sur les informations de son entité.
- Un simple membre pour s'inscrire à des évènements
- Un admin pourra inscrire n'importe quel membre de son entité à un évènement, et pourra également valider les inscriptions des simples membres.
- Un ancien membre aura seulement les droits de lecture/écriture sur son profil perso.
- Un admin aura les droits en lecture/écriture sur l'ensemble des profils perso des membres de son entité.

Voilà en gros pour le fonctionnement du système, lorsque c'est un membre d'une entité B qui se connecte.

On en rajoute une couche :

chaque membre de A peut également se connecter sur l'interface. A la connexion, on lui demande si il souhaite se logger en tant que membre de A, ou bien en tant que B, et si il souhaite se logger en tant que B, il doit choisir sur quel B il souhaite se connecter. Il a alors les droits en lecture (et peut être en écriture), sur l'ensemble des données de l'entité B choisie.

Si il se connecte en tant que membre de A :
en fonction du groupe de persmissions auquel il appartient, il aura : aucun accès/accès en lecture/accès en lecture+écriture aux différents modules du système (gestion des évènements, gestion des audits, gestion des membres, gestion des visites qualité, etc). Si le membre a part exemple les droit en écriture sur le module Audits, il peut créer un nouvel audit, ou éditer un audit existant.

Important : un membre de A peut cumuler différents groupes de permissions. Dans le cas ou il appartient à 2 groupes dont les permissions sont en conflict, il prend les droits les plus permissifs de chaque groupe. Exemple : un membre appartient aux groupe 1 (lecture seule sur le module Audits, lecture/écriture sur le module Evènements), et au groupe 2 (lecture/écriture sur le module Audits, et lecture seule sur le module Evénements), il aura au final les droits suivants : Lecture/écriture sur Audits, lecture/écriture sur Evénements.

Voilà, j'espère avoir résumer le fonctionnement du système à mettre en place, sans avoir été trop compliqué.

Je suis preneur de tout conseil, toute proposition, pour mettre en place un tel système : scripts tout fait, ou desquels s'inspirer , architecture SQL à mettre en place, etc.

Merci d'avance

[CinePhil]

Je crois qu'il faut commencer par modéliser l'univers du discours et donc modéliser les données.

Les membres de chaque entité B sont classés en niveaux : Admin, membre, ancien membre.
Les membre de A sont classés en niveaux : Admin, membre.

J'en déduis qu'un 'membre' appartient à l'entité de type A ou à une entité de type B.
Membre -1,1----Appartenir----0,n- Entite -1,1----Typer----0,n- Type_entite

De plus, chaque type d'entité classe ses membres selon plusieurs niveaux. Il semble également qu'un admin de l'entité de type A n'a pas les mêmes droits qu'un admin d'une entité de type B. ces deux niveaux portant le même nom 'admin' sont différents. Un 'niveau_membre' n'appartient donc qu'à un seul type d'entité.
On arrive alors au MCD suivant :
Type_entite -1,n----Classer----1,1- Niveau_membre

Chaque membre n'est classé que dans un seul niveau, lequel ne peut être choisi que parmi les niveaux de son type d'entité.
Le MCD est le suivant :
Membre -1,1----Classer----0,n- Niveau_membre
Il faut ajouter une contrainte d'inclusion entre les deux associations 'Classer' définies ci-dessus.

Voilà un exemple de la réflexion à mener pour modéliser les données.
Les droits sont ensuites attribués aux niveaux et les membres héritent des droits de leur niveau.

Bon courage pour la suite.

EDIT :
Dans ma réflexion, je n'avais pas fait attention à ce qui suit :

ou être à la fois Admin, et membre d'un pôle.

Dès lors, le MCD est le suivant :
Membre -1,n----Classer----0,n- Niveau_membre

Ou même peut-être une association ternaire :
Membre -1,n----Classer----0,n- Niveau_membre
Pole -0,n--------------|

[van___fanel]

J'en déduis qu'un 'membre' appartient à l'entité de type A ou à une entité de type B.
Membre -1,1----Appartenir----0,n- Entite -1,1----Typer----0,n- Type_entite

un "membre" peut cumuler un poste dans l'entité A, et dans une des entités B. Il peut même cumuler plusieurs postes, dans différentes entités B.

En tout cas merci pour ces réponses. j'espère que cela va m'aider à éclaircir ce sac de nœuds.

[CinePhil]

un "membre" peut cumuler un poste dans l'entité A, et dans une des entités B. Il peut même cumuler plusieurs postes, dans différentes entités B.

Tu viens d'écrire une partie des règles de gestion ; passe à la modélisation !

[Zwiter]

Je te conseil de découper tout ca en entités simples : admin, utilisateur, information, evenement...
Puis de dresser des relations simple :
à un utilisateur correspond 0 ou 1 admin
à 1 utilisateur correspond plusieurs evenements
à 1 evenement correspond une date
etc

C'est long, et fastidieux, mais ensuite, on peut y appliquer des algo de normalisation. En général, on cherche a normaliser en 3e forme normale le système. De la, les tables de la base de données coulent de source !
Z.