Evolution #83
ferméAméliorer l'interface de gestion des droits
100%
Description
L'interface mise en place pour la version 1.2 (ProxyEPN) est globalement satisfaisante pour définir les permissions de chaque profil (Animateur, Coordinateur, Usager, Visiteur).
Mais le système de droits propose également une gestion plus fine, permettant si besoin de définir une politique de droits propre à un utilisateur en particulier.
Si l'interface actuelle permet déjà de définir des permissions au cas pas cas, elle ne fait pas suffisament ressortir ces exceptions. Il serait judicieux de mettre en avant les usagers pour lesquels une politique individuelle a été définie. Aussi à l'édition, les droits par défaut du profil correspondant pourraient apparaitre pour mieux percevoir les changements de ces profils individuels.
Mis à jour par Grégory MARIGOT - TEICEE il y a presque 14 ans
- Version cible mis à ProxyEPN 2.x
Mis à jour par Grégory MARIGOT - TEICEE il y a presque 13 ans
- Statut changé de Nouveau à In Progress
- Version cible changé de ProxyEPN 2.x à ProxyEPN 2.2
- Version ProxyEPN changé de 1.2 à 1.0
Jusqu'à présent l'application se contentait de 2 contextes pour gérer les droits : son EPN et son GEPN (ou "ses" EPN/GEPN avec le cas par exemple d'animateurs multi-sites). Le GEPN représente donc un cloisonnement fort puisqu'on se désintéresse complètement des entités appartenant à d'autres GEPN : l'utilisateur n'y a généralement pas accès.
Mais pour apporter encore plus de finesse dans les permissions il demeurre intéressant de pouvoir définir les droits d'accès aux entités autres (externes à son GEPN). Ceci est particulièrement vrai avec l'apparition de la gestion documentaire, puisqu'on souhaite généralement que celles-ci soient partagées par tous. Mais pour ne pas imposer un mode d'accès aux supports il devient utile de gérer les droits sur ce 3ème contexte (appelé 'OTHER').
Mis à jour par Grégory MARIGOT - TEICEE il y a presque 13 ans
- Statut changé de In Progress à Résolu
- % réalisé changé de 0 à 100
Mise en place du contexte OTHER (r557)¶
La gestion des permissions compte désormais 3 contextes : EPN / GEPN / OTHER
Modification de la base de données :
ALTER TABLE `app_module_rights` ADD `other` SMALLINT NOT NULL DEFAULT '0'; UPDATE `app_module` SET `name`='theme' WHERE `name`='workshop_theme';
Au passage le nom du module concernant les thèmes est raccourci. Il n'était pas utilisé puisque l'édition des thèmes restait un domaine réservé au superadmin, mais cela est amené à évoluer pour devenir paramétrable (cf r54).
Avant le contexte OTHER, tout objet n'appartenant pas aux contextes EPN ou GEPN était considéré extérieur et généralement non accessible à l'utilisateur (exceptions pour les utilisateurs sans contexte comme le superadmin ou à l'opposé les visiteurs anonymes). L'apparition du 3ème contexte permet d'appliquer un niveau de permission paramétrables (par module / role ou utilisateur) plutot qu'une règle en dur par défaut.
Refonte de l'interface d'administration (r560 et r561)¶
Plusieurs modifications de l'interface visent à améliorer l'ergonomie et les fonctionnalités sur la gestion des permissions de l'application :
- personnalisation de droits pour des usagers simples (sans roles)
- liste des utilisateurs disposant de droits personnalisés
- affichage graphique des niveaux de permissions sur les roles
- affichage des niveaux par défaut sur les personnalisations de droits
- édition des niveaux de droits avec curseur jquery-ui
- interface d'édition imposant automatiquement le principe EPN >= GEPN >= OTHER
- remaniement des menus et amélioration des libellés
L'objectif est de rendre l'interface plus pratique et plus claire. Quelques rendus graphiques permettent de mieux visualiser les niveaux attribués à chaque module ou role. Les utilisateurs pour lesquels les droits sont personnalisés peuvent être listés pour ne pas être oubliés, de plus les niveaux du profil par défaut (role de l'usager) sont rappelés pour voir les différences avec la personnalisation.
L'interface d'édition utilise javascript pour maintenir une cohérence dans les permissions : une modification sur un contexte impose un minimum/maximum sur les autres contextes (EPN >= GEPN >= OTHER). Ceci n'est pas une limitation théorique, mais avant tout une aide pratique : dans la plupart des cas il serait possible pour l'application de gérer des niveaux quelconques, mais cela ne présente aucun intérêt à l'usage.
Mis à jour par Grégory MARIGOT - TEICEE il y a plus de 12 ans
- Statut changé de Résolu à Fermé