Rights management » History » Version 11

yllen, 02/19/2013 09:59 AM

1 1 yllen
h1. Rights management
2 1 yllen
3 4 moyo
#918
4 1 yllen
5 1 yllen
6 1 yllen
h2. Analyse
7 1 yllen
8 1 yllen
Contrairement à ce qui est indiqué dans le ticket, j'avais envie de partir sur une voie différente.
9 1 yllen
Je m'explique :
10 1 yllen
11 1 yllen
On partais du principe que r < u < c < d < p
12 1 yllen
ce qui signifiais que si tu avais le droit de purge, cela sous-entendais que tu avais tous les autres droits.
13 1 yllen
Seulement, en regardant les demandes du forum, on s'aperçoit que les sociétés veulent affiner les droits.
14 1 yllen
Par exemple, chez nous, le service économat/achats qui réceptionne le matériel à le droit de créer une machine (injection du bon de livraison à la réception du matériel) mais n'a pas le droit de le mettre à jour (gérer par le service informatique).
15 1 yllen
16 1 yllen
Donc, mon idée étais de partir sur une valeur numérique pour chaque droit :
17 1 yllen
Aucun => 0
18 1 yllen
Lecture => 1
19 1 yllen
Mise à jour => 2
20 1 yllen
Création => 4
21 1 yllen
Suppression => 8
22 1 yllen
Purge => 16
23 1 yllen
24 1 yllen
avec dans le formulaire une dropdown multi sélect et l'enregistrement en base de la valeur cumulée.
25 1 yllen
26 1 yllen
Cela permet d'avoir une gestion plus claire pour les utilisateurs => tu n'as les droits que sur ceux sélectionnés dans la dropdown.
27 1 yllen
28 1 yllen
29 1 yllen
30 1 yllen
h2. Réalisation
31 1 yllen
32 1 yllen
Modifier la table glpi_profiles pour remplacer le type des objets (computer, moniter...) de char(1) NULL en int(2) NOT NULL DEFAULT 0
33 1 yllen
avec migration des données
34 1 yllen
r => 1
35 1 yllen
w => 31
36 1 yllen
37 1 yllen
Adaptation de la fonction Session::haveRight
38 1 yllen
39 1 yllen
Ajout de CONSTANT dans la commonDBTM
40 1 yllen
const READ = 1
41 1 yllen
const UPDATE = 2
42 1 yllen
const CREATE = 4
43 1 yllen
const DELETE = 8
44 1 yllen
const PURGE = 16
45 1 yllen
46 1 yllen
2 propositions pour la classe commonDBTM
47 2 yllen
- ajouter une propriété $rightname qui correspond au nom du champ dans la table glpi_profiles 
48 1 yllen
  et dans le canView par exemple, faire un Session::haveRight
49 1 yllen
  => avantage : pas besoin de redéfinir le canView dans la classe de l'objet
50 8 yllen
OU
51 2 yllen
- passer le classe commonDBTM en abstract ainsi que les functions can...
52 1 yllen
  => avantage : on est certain que l'on se sera poser la question des droits dans la classe de l'objet
53 1 yllen
54 1 yllen
55 9 ddurieux
56 9 ddurieux
_David_ : le choix 1 permet de simplifier ;)
57 9 ddurieux
58 9 ddurieux
59 9 ddurieux
60 8 yllen
Quel que soit le choix retenu, il faut 5 can : canView, canUpdate, canCreate, canDelete, canPurge
61 3 yllen
62 3 yllen
Cas tordus :
63 3 yllen
64 3 yllen
- pour les dropdowns, il ne semble pas y avoir de problème
65 5 yllen
66 5 yllen
- pour les droits de création, modification, suppression et purge d'un fils, le droit doit être de pouvoir modifier le père
67 5 yllen
  (ex : pour ajouter un disque, je dois avoir le droit de modifier l'ordinateur)
68 5 yllen
69 5 yllen
- pour les relations, on doit avoir le droit de lire les 2 objets et d'en modifier l'un des 2
70 6 yllen
71 7 yllen
- pour les multi droits sur un objet (ex des suivis), il suffit de neutraliser le bit correspondant au 5 principaux si non utilisé et d'en ajouter des supplémentaires
72 7 yllen
Aucun => 0
73 7 yllen
Lecture => 1
74 7 yllen
Mise à jour => 2
75 7 yllen
add_followup => 4
76 7 yllen
Purge => 16
77 7 yllen
group_add_followup => 32
78 7 yllen
global_add_followup => 64
79 7 yllen
(le bit 8 est neutralisé car il n'y a pas de corbeille pour un suivi)
80 7 yllen
81 7 yllen
Ce principe est un principe ouvert qui permet d'ajouter si besoin des bit supplémentaires au fur et à mesure de l'évolution du logiciel.
82 7 yllen
Il permet aussi de pouvoir être appliqué à d'autre objet comme les ordinateurs (plusieurs demandes dans le forum pour n'autoriser que la vision de mes ordinateurs ou des ordinateurs de mon groupe)
83 7 yllen
84 7 yllen
85 6 yllen
86 6 yllen
Pour le ticket 1474
87 6 yllen
- pour permettre au plugin d'ajouter leurs droits, je pense qu'il faut en profiter pour restructurer la table glpi_profiles en supprimant les colonnes correspondant à un objet et les insérer, au besoin, en ligne, ce qui permettra à un plugin d'ajouter ses propres droits
88 6 yllen
On aurait donc plus que 4 colonnes : id, name, interface, is_default, value
89 10 moyo
90 10 moyo
MoYo : 
91 10 moyo
* L'ensemble me semble cohérent. 
92 10 moyo
* Je ne comprend pas la dernière remarque concernant le ticket 1474. 
93 11 yllen
94 11 yllen
  Nelly : si j'ai bien compris le ticket 1474, c'est pour permettre aux plugins d'utiliser les profiles du coeur sans les redéfinir.
95 11 yllen
          Donc je proposais de supprimer les colonnes computer, phone, monitor... et à la place, d'ajouter une ligne avec par exemple name = Computer et value = chiffre (+ les interface et is-value bien sur)
96 11 yllen
          Comme ça, le plugin viendrait écrire dans cette table avec name = nom du plugin et value = chiffre
97 11 yllen
98 10 moyo
* L'idée du $rightname dans CommonDBTM permettrait effectivement de gérer la majorité des cas simples. 
99 10 moyo
* Sur le positionnement des constantes (const READ = 1...), j'ai quelques doutes. Elle devrait peut-être plutôt se situer dans ProfileRight ?
100 10 moyo
* Un des prérequis à cette nouvelle gestion me semble t'il serait de revoir la gestion multi-select (exemple : http://www.erichynds.com/examples/jquery-ui-multiselect-widget/demos/ sur le chantier [[ExtjsToJquery]])