Rights management » History » Version 4
moyo, 02/15/2013 11:16 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 | 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 |