Permissions / héritages dossiers

[Pymento]

Bonjour à tous, j'ai un soucis d'ordre conceptuel.

Je vous plante le décor:

Code :

1
2
3
4
5
6
7
8
9
USERS (id,nom)
GROUPES(id,nom)
USER_APPARTIENT_GROUPE(#id_user,#id_groupe)
ELEMENTS(id,nom,#id_parent) -> id_parent est de type ELEMENTS.

Et éventuellement une table

GROUPE_PERMISSION_ELEMENT(#id_groupe,#id_element,lecture,ecriture,suppression) ->lecture/ecriture/suppression sont des BOOL

Mon soucis c'est d'optimiser ma base de donnée.
La solution brutale serait pour chaque element et pour chaque groupe une entrée dans GROUPE_PERMISSION_ELEMENT.

Ensuite j'avais pensé à d'autre du type considérer que s'il n'y à pas d'entrée, c'est une restriction automatique s'il y a entrée alors permettre les booléens activé. Ou complètement l'inverse une autorisation automatique et une restriction si il y a entrée. Ou même un mix des deux, càd la lecture en autorisation auto et écriture/suppression en restriction auto.
(je sais pas si j'ai été assez clair)

Mais cela dis mon problème principal, serait au niveau des profondeurs d'éléments(c'est une gestion de dossier). j'aimerai pouvoir me passer de triggers/requêtes stockées qui feraient:

Code :

1
2
3
Quand j'ajoute une "règle" dans la table permission
->recursif: pour chaque fils ajouter la même règle.

Une façon optimale de dire si je bloque ce dossier de toute façon il n’accédera pas aux autres, si j'autorise certaines chose les élements suivant en hériteront.


Je suis conscient que c'est un peu fouillis comme explication, donc n'hésitez pas à me demander des précisions.

Merci.

[Richard_35]

Bonjour Pymento,

Envoyé par Pymento

Mais cela dis mon problème principal, serait au niveau des profondeurs d'éléments(c'est une gestion de dossier). j'aimerai pouvoir me passer de triggers/requêtes stockées qui feraient:
Quand j'ajoute une "règle" dans la table permission
->recursif: pour chaque fils ajouter la même règle.

==> Effectivement, il faut à tout prix éviter cela. D'autant qu'il faudrait également prévoir la suppression d'une règle ou sa modification.


Tout d'abord, juste un point MCDesque : ton entité

Envoyé par Pymento

USER_APPARTIENT_GROUPE(#id_user,#id_groupe)

veut dire qu'un user peut appartenir à plusieurs groupes. Est-ce bien le cas ?

[Pymento]

Oui exactement.

[Richard_35]

Autre chose :

Envoyé par Pymento

ELEMENTS(id,nom,#id_parent) -> id_parent est de type ELEMENTS.

Envoyé par Pymento

GROUPE_PERMISSION_ELEMENT(#id_groupe,#id_element,lecture,ecriture,suppression) ->lecture/ecriture/suppression sont des BOOLEENS

==> 2 questions :

1. dans GROUPE_PERMISSION_ELEMENT, il semble que tu souhaites établir des autorisations au niveau "groupe", et non pas "descendre" au niveau "user". Est-ce bien cela ?
2. dans GROUPE_PERMISSION_ELEMENT, souhaites-tu établir des autorisations au niveau "élément simple" et au niveau "élément parent" ?

[Pymento]

Envoyé par Richard_35

Autre chose :==> 2 questions :

1. dans GROUPE_PERMISSION_ELEMENT, il semble que tu souhaites établir des autorisations au niveau "groupe", et non pas "descendre" au niveau "user". Est-ce bien cela ?
2. dans GROUPE_PERMISSION_ELEMENT, souhaites-tu établir des autorisations au niveau "élément simple" et au niveau "élément parent" ?

1) Effectivement je me suis dis justement que ça optimiserai le système. Je n'ai pas besoin d'autant de précision.

2) J'ai pas très bien saisie, mais en gros c'est es ce que si je donne la lecture à un element, il faut forcément que la lecture soit donnée aussi à son parent ?

Et c'est justement cet aspect la ou je 'bloque'. ou alors je n'ai pas bien compris la question

[Richard_35]

Envoyé par Pymento

2) J'ai pas très bien saisie, mais en gros c'est es ce que si je donne la lecture à un element, il faut forcément que la lecture soit donnée aussi à son parent ?

==> Non, ce n'est pas ce que j'ai voulu te demander.

Veux-tu pouvoir indiquer un parent dans #id_element de GROUPE_PERMISSION_ELEMENT ?
==> avec pour conséquence de rendre valable les autorisations indiquées pour tous ses enfants.

Veux-tu pouvoir, malgré tout, indiquer un élément non-parent dans #id_element de GROUPE_PERMISSION_ELEMENT ?
==> avec pour conséquence de pouvoir agir sur un élément, en particulier, sans tenir compte des éventuelles autorisations du parent auquel il est attaché.

[Pymento]

Je rajoute au passage que ma profondeur, est grande et indéfinie et que l'id_parent peut être null, c'est pour ça que je ne comprend pas forcément pourquoi me demandes tu si je veux mettre une "profondeur" dans mon id_element dans la table permission...

Je reprend un peu mon explication, peut être nous somme nous mal compris.
Donc mon #id_element fait référence à un dossier

En gros avec l'id d'un element je vais pouvoir obtenir son parent dans la table Elements et ses groupes associés avec leurs droits dans la table Permission.

Enfait il me manque la manière d'insérer dans la table permission. Ou alors une façon différente de procéder.

Désolé si je vous fait répéter.

[Richard_35]

Bonjour Pymento,

Bien, reprenons par l'exemple.

USERS (id,nom) :

Code :

1
2
3
4
5
6
id  nom
1   user1
2   user2
3   user3
4   user4
...

GROUPES (id,nom) :

Code :

1
2
3
4
5
id  nom
1   groupe1
2   groupe2
3   groupe3
...

USER_APPARTIENT_GROUPE (#id_user,#id_groupe) :

Code :

1
2
3
4
5
id_user id_groupe
1       1
3       1
2       2
...

A ce niveau, notes que si

Envoyé par Richard_35

dans GROUPE_PERMISSION_ELEMENT, il semble que tu souhaites établir des autorisations au niveau "groupe", et non pas "descendre" au niveau "user". Est-ce bien cela ?

Envoyé par Pymento

1) Effectivement je me suis dis justement que ça
optimiserai le système. Je n'ai pas besoin d'autant de précision.

alors user4
n'aura aucune autorisation puisqu'il n'est attaché à aucun groupe.


ELEMENTS (id,nom,#id_parent)

Envoyé par Pymento

-> id_parent est de type ELEMENTS

Code :

1
2
3
4
5
6
id  nom      id_parent
1   élément1 
2   élément2 élément1
3   élément3 élément1
4   élément4 élément2
5   élément5

A ce niveau, notes qu'une boucle infinie est vite arrivée !... si :

Code :

1
2
3
4
5
6
id  nom      id_parent
1   élément1 élément4
2   élément2 élément1
3   élément3 élément1
4   élément4 élément2
5   élément5

==> nous sommes très mal !... il faudra tester la chose.

Enfin, et c'est en fait l'objet de ma dernière question :
GROUPE_PERMISSION_ELEMENT (#id_groupe,#id_element,lecture,ecriture,suppression) :

Code :

1
2
3
4
id_groupe id_element lecture ecriture suppression
1         1          vrai    faux     faux
1         3          vrai    frai     vrai
...

==> l'élément 1 est de type enfant ET parent, alors que l'élément 3 n'est QUE de type enfant. Veux-tu pouvoir paramétrer cela ou ne paramétrer QUE des parents ?

En relisant tes interrogations, je crains que tu confondes la conception de la base de données et les processus (les programmes) qui vont l'utiliser. En effet, la conception ne résout pas tout ; les programmes vont se baser sur la conception pour faire respecter "la règle du jeu" (les règles de gestion de l'application).

En fonction de ce que tu vas décider, il y aura un programme qui, à chaque tentative d'accès à tes "éléments", balayera tes tables pour savoir si, en final, le demandeur possède les bonnes autorisations.

[dba01]

En somme : que tous les droits accordé à un Niveau soient automatiquement reportés sur les Sous-Niveaux qui en dépendent.

Mais avec possibilité d'écraser un des Sous-Niveaux, avec un nouveau report sur les Sous-Sous-Niveaux suivants, etc...

Et ces droits enregistrés en base et non dans le programme, qui ne fera qu'appliquer au cas par cas au niveau final, où qu'il se trouve, selon les dernières conditions valables (en remontant la liste).

C'est ça ?

[dba01]

Mais alors ...
Si tu modifie un niveau "père", faudra revisiter tous les niveaux "descendants" qui auront été écrasés.

[Pymento]

Envoyé par Richard_35

Bonjour Pymento,
A ce niveau, notes que si alors user4
n'aura aucune autorisation puisqu'il n'est attaché à aucun groupe.

Je peux résoudre ce problème en ayant un groupe TOUS. Mais effectivement le but étant de limiter des branches & dossiers. Et non pas de simplement protéger certains dossiers à un seul utilisateur

Envoyé par Richard_35

A ce niveau, notes qu'une boucle infinie est vite arrivée !... si :[code]

Justement dans mes process ect... je ne permet pas d'arriver à une boucle infini. Donc pas de pb de ce coté là.

Envoyé par Richard_35

Veux-tu pouvoir paramétrer cela ou ne paramétrer QUE des parents ?

En relisant tes interrogations, je crains que tu confondes la conception de la base de données et les processus (les programmes) qui vont l'utiliser. En effet, la conception ne résout pas tout ; les programmes vont se baser sur la conception pour faire respecter "la règle du jeu" (les règles de gestion de l'application).

En fonction de ce que tu vas décider, il y aura un programme qui, à chaque tentative d'accès à tes "éléments", balayera tes tables pour savoir si, en final, le demandeur possède les bonnes autorisations.

D'une part effectivement je pense que la modélisation base de donnée est très limité c'est plus vers le moyen de l'utiliser. Et c'est justement la ou je veux optimiser. J'ai pensé que cette partie du forum était la plus adéquate pour poser ma question.

Mes interrogations se portent sur le nombre d'entrée à affecter, de toute façon des 'seulement' enfants seront peut être amenés à devenir des parents, c'est pourquoi il faut que je puisse mettre en place le même mode de fonctionnement pour tout les élements.

Concrètement et pour aussi répondre à #dba01, c'est exactement ça, Si je ne spécifie pas de règles, ils agissent comme leur père jusqu'a que j'en définisse.



//////////////////////////////////////

J'ai les idées un peu plus claires maintenant, arrêtez moi si vous trouvez des incohérences:

Aucun de mes éléments sont accessibles de base, je vais pour chaque groupe leur donner accès en lecture a un élément racine, de là, ils vont pouvoir accéder à toute la profondeur du dossier, jusqu'a que je décrète qu'un tel dossier ne pourra être lu que par un et un seul groupe. Pareil pour l'écriture et modification.
Pour chaque appel j'irai dans ma base de donnée vérifier si il existe une règle à appliquer dans le cas contraire je conserve celle du parent (avec des input hidden, pour m'éviter plus d'accès à la base)

ça me réduit donc le nombre d'entrée au simple règles sur un dossier "bifurcatif" ( ouai je viens d'inventer le terme !).

N'hésitez pas à donner votre avis et vos doutes.

[Richard_35]

Bonjour Pymento et Dba01,

Envoyé par Pymento

Pour chaque appel j'irai dans ma base de donnée vérifier si il existe une règle à appliquer dans le cas contraire je conserve celle du parent (avec des input hidden, pour m'éviter plus d'accès à la base)

==> tu as tout dit.

[CinePhil]

Il me semble avoir été confronté à un problème similaire, dans un temps qui commence à être lointain où j'étais responsable qualité...

Les procédures étaient affectées à des groupes de destinataires et certains destinataires avaient, en plus des procédures de leur(s) groupe(s), des procédures spécifiques à appliquer.
J'avais alors résolu le problème en créant une table pour l'attribution de ces seules procédures spécifiques et j'avais donc ce schéma :
procedure -0,n----affecter----1,n- groupe -1,n----comprendre----0,n- destinataire
|---------------0,n----affecter_specifiquement----------------------------0,n----------|

Pour avoir la liste des procédures affectées à une personne, je faisais une union de deux requêtes traduisant les deux associations "affecter".

Dans ton cas, si j'ai bien compris ton besoin, tu pourrais affecter prioritairement des droits aux dossiers à des groupes puis dans une autre table les droits spécifiques qui diffèrent des droits des groupes.

[Pymento]

@CinePhil
Ca peut être effectivement une solution à envisager pour une future amélioration, mais pour l'instant je souhaite seulement me cantonner aux droits de base d'un groupe. Lecture/écriture.

Par contre pour rebondir sur la post-solution, c'était trop beau et trop simple pour être vrai
Malheureusement garder en mémoire les règles du derniers parent ne suffit pas car je suis sur une interface ou tout les éléments restent disponibles. Càd que je vais pouvoir cliquer sur n'importe quel élément pourvu qu'il est sur le chemin de l'élément en cours

Code :

1
2
3
4
5
6
7
8
9
toto
  1
  2
    a
    b
  3
titi
tata

alors j'ai seulement deux solutions assez lourdes:

1.Comme depuis le début, une entrée pour chaque groupe pour chaque élément.

+++ : pour la consultation un petit select pour obtenir les droits
- - - : taille de la table, et update recursif lors d'un changement

2.Sinon, mettre seulement une entrée par spécification. et lors de la consultation faire une requête stockée qui va récupérer les derniers droits valables.

+++: optimisation du nombre d'entrée
- - - : requête lourde? pour chaque mouvement de repertoire.



maintenant les droits ne se paramètre que très rarement, alors que la navigation elle est constante et surtout multiple.
Donc je penche pour la 1. Mais ça me fais revenir à mon point de départ !