Rights management » History » Version 6

yllen, 02/15/2013 07:26 PM

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 1 yllen
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 2 yllen
Suivant le choix retenu, il faut 5 can : canView, canUpdate, canCreate, canDelete, canPurge)
56 3 yllen
57 3 yllen
Cas tordus :
58 3 yllen
59 3 yllen
- pour les dropdowns, il ne semble pas y avoir de problème
60 5 yllen
61 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
62 5 yllen
  (ex : pour ajouter un disque, je dois avoir le droit de modifier l'ordinateur)
63 5 yllen
64 5 yllen
- pour les relations, on doit avoir le droit de lire les 2 objets et d'en modifier l'un des 2
65 6 yllen
66 6 yllen
67 6 yllen
Pour le ticket 1474
68 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
69 6 yllen
On aurait donc plus que 4 colonnes : id, name, interface, is_default, value