Rights management » History » Version 6

« Previous - Version 6/13 (diff) - Next » - Current version
yllen, 02/15/2013 07:26 PM


Rights management

#918

Analyse

Contrairement à ce qui est indiqué dans le ticket, j'avais envie de partir sur une voie différente.
Je m'explique :

On partais du principe que r < u < c < d < p
ce qui signifiais que si tu avais le droit de purge, cela sous-entendais que tu avais tous les autres droits.
Seulement, en regardant les demandes du forum, on s'aperçoit que les sociétés veulent affiner les droits.
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).

Donc, mon idée étais de partir sur une valeur numérique pour chaque droit :
Aucun => 0
Lecture => 1
Mise à jour => 2
Création => 4
Suppression => 8
Purge => 16

avec dans le formulaire une dropdown multi sélect et l'enregistrement en base de la valeur cumulée.

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.

Réalisation

Modifier la table glpi_profiles pour remplacer le type des objets (computer, moniter...) de char(1) NULL en int(2) NOT NULL DEFAULT 0
avec migration des données
r => 1
w => 31

Adaptation de la fonction Session::haveRight

Ajout de CONSTANT dans la commonDBTM
const READ = 1
const UPDATE = 2
const CREATE = 4
const DELETE = 8
const PURGE = 16

2 propositions pour la classe commonDBTM
- ajouter une propriété $rightname qui correspond au nom du champ dans la table glpi_profiles
et dans le canView par exemple, faire un Session::haveRight
=> avantage : pas besoin de redéfinir le canView dans la classe de l'objet

- passer le classe commonDBTM en abstract ainsi que les functions can...
=> avantage : on est certain que l'on se sera poser la question des droits dans la classe de l'objet

Suivant le choix retenu, il faut 5 can : canView, canUpdate, canCreate, canDelete, canPurge)

Cas tordus :

- pour les dropdowns, il ne semble pas y avoir de problème

- pour les droits de création, modification, suppression et purge d'un fils, le droit doit être de pouvoir modifier le père
(ex : pour ajouter un disque, je dois avoir le droit de modifier l'ordinateur)

- pour les relations, on doit avoir le droit de lire les 2 objets et d'en modifier l'un des 2

Pour le ticket 1474
- 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
On aurait donc plus que 4 colonnes : id, name, interface, is_default, value