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.