Discussion :

[pynnott]

Bonjour à tous,

Voila pour une gestion des utilisateurs de mon application j ai besoin de gere des roles pour chaque utilisateur jusqu'à la aucun soucis la facon que je procède est la suivante je creer plusieur role et assigne les role possible à un utilisateur. Lors de sa connection il choisi le role a utilisé lors de cette session car un utilisateur peu exemple être chef un jour et un autre simple employé jusqu'à la tout beigne où je bloque est dans le fait que suposon un utilisateur à le droit de réinitialiser un mot de passe comment géré le fait qu il ne peu réinitialiser un mot de passe d un utilisateur qui serai exemple son supérieur . Sans ajouté chaque ID de compte qu il peu ou ne peu pas. Je penssais au groupe d utilisateur mais cela devien vite dificile a gere non ? Alors je me tourne vers vous pour peut être avoir d autre solution merci d'avance pour votre aide!

[CinePhil]

je creer plusieur role et assigne les role possible à un utilisateur

J'ose espérer que vous avez alors une structure de données qui ressemble à ça :

MCD :
utilisateur -1,n----assigner----0,n- role

Tables :
utilisateur (uti_id, uti_login...)
role (rol_id, rol_code, rol_libelle...)
uti_assigner_rol (uar_id_utilisateur, uar_id_role...)

suposon un utilisateur à le droit de réinitialiser un mot de passe comment géré le fait qu il ne peu réinitialiser un mot de passe d un utilisateur qui serai exemple son supérieur

Il vous faut une structure de données qui enregistre la hiérarchie.

Règle de gestion :
Un utilisateur peut encadrer plusieurs utilisateurs et un utilisateur peut être encadré par un seul utilisateur.

MCD :
utilisateur -0,n---encadrer
|-------------0,1--------|

Table :
uti_encadrer_uti (ueu_id_utilisateur, ueu_id_encadrant...)

Dès lors, vous pouvez savoir par une requête quels sont les personnes qu'encadre l'utilisateur 12 :

Code SQL :

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

1
2
3
4
SELECT u.uti_id, u.uti_login
FROM utilisateur u
INNER JOIN uti_encadrer_uti e ON e.ueu_id_utilisateur = u.uti_id
WHERE e.ueu_id_encadrant = 12

Et de là, vous pouvez activer ou pas la fonction de changement de mot de passe.

[pynnott]

Pour la structure de donnée des roles en effet c'est exactement ce que je fais pour ce qui est de votre solution mon problème est qu'il n'y a pas qu'un seul utilisateur qui peu encadré des utilisateurs peu être c'est exemple sera plus parlant imaginée un equipe dont quelques employés les plus bas ds la hiérarchie peuvent etre sois chef d equipe sois employé, de plus 3 superviseurs (poste superieur au chef d'équipe) sont en rotation sur deux semains chacun. Ce qui me donne 3 utilisateurs du meme niveau mais qui ne pourrons utilisé des fonctions que sur des compte inférieur à eux. L'exemple de mon dernier poste la réinitialisation de mot de passe n'est qu'une fonction mais plusieurs autre ont un schéma de droit semblable. Peu être la facon de fonctionné n'est pas la bonne et c est pour cela que je ne trouve pas de facon simple de faire ?

[pynnott]

A bien réfléchir peu être que de mettre une valeur de 0 à 100 aux roles ainsi qu une valeur 0 1 me permettent de dire si le role peu modifier un niveau egale a lui. le tout en enregistra la plus forte valeur dans la table de liaison des roles - utilisateurs penssez vous qu il y à plus simple?

[CinePhil]

un equipe dont quelques employés les plus bas ds la hiérarchie peuvent etre sois chef d equipe sois employé, de plus 3 superviseurs (poste superieur au chef d'équipe) sont en rotation sur deux semains chacun

Vous n'aviez pas évoqué jusque là cette notion de planning mais ce n'est pas insurmontable.

Première approche rapide à cette heure avancée (0h50 en France au moment où j'écris) : l'ajout d'une date de début et d'une date de fin dans la table associative uti_encadrer_uti.
Ainsi, selon la date de connexion, on sait si l'utilisateur est encadrant ou encadré.

Bonne nuit !

[Invité]

slt

Peu être la facon de fonctionné n'est pas la bonne et c est pour cela que je ne trouve pas de facon simple de faire ?

si c'est la bonne des que tu commences à scaler. Les gestions user 1 user c'est à proscrire...

une façon très simple c'est de décrire des usecase:
je suis utilisateur:

je peux changer les mots de passes de "mes" n-1
je peux peut etre changer le mot de passe d'un utilisateur independamment de la hiérarchie
je peux avoir une interdiction de changer le mot de passe d'un n-1

raffinement:
je suis utilisateur de rang n
je me connecte en rang p (p<n)
6) je peux changer les mots de passe de mes p-1

Tu peux considérer le role, pwdManager: un mec qui change les mots de passe n-1
Les actions du role c'est:
- changer pwd

tu peux rajouter une règle d'exceptions. Ca c'est le plus ballourd.
u1, u2, changer/pas changer

user->1groupe->n roles -> n actions
user->1loginGroupe->1groupe
user->n regles
groupe->n groupe

user->1groupe c'est son groupe/rang le plus haut pour respecter 6): on peut à priorichanger le mdp de quelqu'un non loggé(...), mais dans ce cas là il faut que l'utilisateur dont le mdp est changé en question ait un groupe.

Tout groupe a plusieurs roles ... dont un qui est pwdManager

pwdManager ne permet pour toi que de gérer le reinit de pwd (-voir pwd? brr)

user->logingroupe definit la relation avec le groupe par lequel l'utilisateur est loggé. Un moyen très simple de différencier du groupe c'est que les deux ont pas même durée de vie: l'un advitam, lautre le temps d'une session.

groupe->n groupe decrit simplement la relation (supérieure?) entre deux groupes.
Pour toi tu as pris la relation (ordre sur N) qui définit un "arbre" 1-aire dont la tete c'est le chef, mais cest ptet pas tjs ca. Imagine
chef
sales tech <--ptet sales faut pas leur permettre ce genre de chose
... ...

groupe->n groupe te permet de représenter un ordre plus fin.

//la visualisation parce que c'est tjs bien de vérifier que son modèle repond aux usecase...
user::logingroupe::groupe::pwdManager?
user::logingroupe::groupe::pwdManager::changerPwd?
g2 = user2::groupe
ok = user::regles::with(u2)
ok == true: changer
ok == false: quitter
user::logingroupe::groupe::existeRelation(g2)?
ok changer

[pynnott]

salut à vous deux

galerien69,

donc si je résume à ma façon ce que j'ai compris de ce que vous proposez ce serait:

De mon coté j'ai cette configuration:

table des droits d'access avec les enregistrement en binaire pour chaque module ce qui me permet de voir les droits fin autorisé

une table role qui enregistre les roles exemple superviseur qui est lier à un couple de la table de droit

et ma table utilisateur

de ton côté ce que je comprend je devrais faire plutôt une nouvelle table exemple groupe que j'utiliserai pour faire la hiérarchie de tout sa elle serai placé entre la table de role et la table utilisateur.

Cinephil

Dans votre approche le seul problème que je vois est pour la function de réinitialisation du mot de passe pour toute les autres cela fonctionnerai bien. Dans ce cas précis l'utilisateur n'est pas connecté car il a besoin de faire réinitialisé son mot de passe avant , comment cette utilisateur peu être défini comme inférieur à un autre ? Car si je comprend bien tout compte non connecté deviendrai inférieur au autre ? Peu être je n'est pas bien compris votre approche ....

[Invité]

une table role qui enregistre les roles exemple superviseur

non.

le superviseur n'est pas un role, le superviseur est un groupe.
par exemple le groupe superviseur peut avoir plusieurs roles:
pwdManager...
planningManager...
alors que le groupe agentEntretien a plutot les roles
pwdManager...
pointeur...

Au role pwdManager tu as pr ton cas une seule action qui est changer password

pour faire la hiérarchie de tout sa elle serai placé entre la table de role et la table utilisateur.

oui. mais attention ta "table" hiérarchie n'est pas liée à la table de role. Uniquement à groupe. (deux fois, pour mettre un groupe en relation avec un autre, c'est suffisant)

[CinePhil]

La gestion par groupe d'utilisateurs est effectivement meilleure mais ce n'était pas, a priori, la problématique posée au départ.

Vite fait, voici le genre de MCD qu'on peut construire :

Utilisateur -1,n----appartenir----0,n- Groupe -1,n----avoir----0,n- Droit

On peut aussi modéliser les cas particuliers. En plus des droits obtenus via son appartenance à un ou des groupes, un utilisateur peut avoir des droits spécifiques. On peut alors ajouter l'association ci-dessous. Mais attention à la redondance de données ! Il faudra prévoir un mécanisme interdisant cette redondance.

Utilisateur -0,n----avoir_specifiquement----0,n- Droit

[pynnott]

Merci énormément de votre aide cela ma permis de voir plus claire dans tout cela