GLPI-PROJECT

h1. Rights management

#918

h2. 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.

h2. 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

OU

- 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

Quel que soit 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 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

Aucun => 0

Lecture => 1

Mise à jour => 2

add_followup => 4

Purge => 16

group_add_followup => 32

global_add_followup => 64

(le bit 8 est neutralisé car il n'y a pas de corbeille pour un suivi)

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.

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)

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