Independent agent roles per organisation

Created by: adipasquale

Grosse PR, pour changer. Une grande partie des changements vient de renommages toutefois, notamment dans les specs

Introdution du modèle AgentRole

La table de jointure Agents - Organisations devient un véritable modèle AgentRole qui possède pour l'instant un seul attribut propre : le level , valeurs possibles : basic (defaut) ou admin

Justifications des nommages :

• J'aime bien avoir des noms parlants pour les modeles, meme les tables de jointures. Ici ce n'est pas super évident de nommer le lien entre un agent et une orga. Role est pas mal, même si c'est un peu ambigu avec le "niveau" du rôle agent/admin qui est ici une caractéristique
• je pense qu'à l'avenir on va peut-être/probablement permettre aux agents d'appartenir à plusieurs services. Dans la modélisation proposée, il "suffira" de déplacer le service de l'agent vers l'AgentRole, et de relâcher un peu la contrainte d'unicité.
• Rôle me semble suffisament générique dans ce cadre, et il me semble resterait à peu près acceptable si on rajoutait le service
• j'ai renommé le niveau de base de "agent" vers "basic", dans le but de rendre ça plus greppable, et d'éviter la polysémie existante entre un agent agent et un agent admin. Je n'ai pas répercuté ça dans l'UI pour l'instant, on parle toujours d'agent, pas de rôle basique.
• je n'ai pas renommé la table, elle s'appelle toujours agents_organisations . ce n'est pas hyper evident de renommer une table donc je préfère m'économiser ça.

Ces choix sont très discutables.

Policies

C'était moins douloureux que ce que j'envisageais de gérer les permissions dans les policies. le gros truc était de déplacer la méthode can_access_others_planning? des agents vers l'AgentRole

Par contre ça devient pas mal absurde ce qu'on fait pour les routes de niveaux départements, il faut qu'on attaque le sujet pour introduire le modèle département et les permissions qui s'y réfèrent rapidement

petite complexité supplémentaire pour le scope des absences, la seule ressource exposée depuis l'API et qui peut donc être récupérée en dehors du contexte d'une orga

PermissionsController devient AgentRolesController

Les routes d'éditions d'agents existantes sont sur un controlleur non-AR qui s'appelle Permissions; qui devait j'imagine préfigurer les AgentRole. J'ai supprimé complètement la notion de Permission

Ce n'est pas tout à fait cohérent car je n'ai pas déplacé la route Agents#index vers AgentRoles, mais je pense que c'est a peu pres acceptable, en tout cas mieux que permissions

Specs

Dans les specs, ca devient un peu ambigu de faire create(:agent, organisations: []), meme si ca continue à fonctionner. J'ai rajouté des helpers pour pouvoir faire create(:agent, basic_role_in_organisations: [...]) et create(:agent, admin_role_in_organisations: [...]) pour rester explicite, et j'ai migré tous les appels du code existant

Complexifications des formulaires d'invitation et de creation d'orga

Je m'appuie au max sur la possibilité de créer des objets imbriqués native de rails grace à accepts_nested_attributes_for . Dans le cas de la création d'une orga ca va assez loin puisque j'imbrique la création d'un agent et la création d'un agentrole pour cet agent 🤯 ca fonctionne et ca evite du code custom, au détriment de rendre ca un peu moins explicite, il faut bien connaitre rails.

Migration

Pas de questions particulières je copie juste la valeur d'agent vers agent_roles et a partir de maintenant elles pourront évoluer indépendemment.

Il faudra dans un ticket successif supprimer la colonne agents.role

testée sur les données de prod √

Contrainte un admin par orga

J'introduis la contrainte qu'il doit toujours y avoir un admin par orga. par conséquent : interdit de dégrader ou supprimer le dernier admin. Ce n'est pas méga évident à exprimer dans le système de validations AR, je pense être arrivé à qqch d'acceptable.

modifications de l'UI

Dans la liste des orgas, j'affiche un petit icône pour distinguer celles où l'agent courant est admin

Dans la liste des agents j'ai déplacé l'info admin vers une colonne à part plutôt qu'un badge

Dans le formulaire d'un agent, j'ai rajouté une infobox pour prévenir du changement

Bonus

• regroupement du comportement commun des policies niveau département (== celles de la secto)
• l'enum agent.roles 0/1 devient une colonne level string lisible dans la table des AgentRoles
• je supprime deux helpers un peu louches human_enum_name_html
• on enleve un -> { distinct } bizarre sur les associations entre agents et orgas

A bien tester sur la review app

• Org creation from homepage
• sectorisation interface
• invite an agent
• manage agents roles

Note : l'invitation d'un agent depuis la super admin plante pour les review apps, mais je suis quasiment sûr que ce n'est pas lié à cette PR, ça doit dater du dernier changement sur les emails d'invitations et au fait que la super admin sur les review apps n'est pas authentifiée pareil. Ca fonctionne bien en local