Mise en place de pundit pour le super_admin et ajout du role support

[Holist]

Close : #3696 #3912 #3788 gip-inclusion/rdv-insertion#1543

Interface pour le rôle de super_admin :

Enregistrement.de.l.ecran.2023-12-19.a.10.31.44.mp4

Interface pour le rôle de support :

Enregistrement.de.l.ecran.2023-12-19.a.10.33.27.mp4

Cette PR corrige diverses issues concernant le super_admin.

Il s'agit dans un premier temps de modification concernant les associations dans les formulaires pour éviter les erreurs et faciliter la vie du support (dans ce commit)

Le reste de la PR concerne de la suppression de code inutile et la mise en place pundit pour le super_admin avec des policies à false par défaut, l'ajout de l'enum role pour le model SuperAdmin permettant d'avoir des policies adaptés en fonction du rôle du membre de l'équipe connecté.

J'en profite pour mettre à jour administrate. J'ai mis à jour les templates de la gem qui avaient changés.

J'ai également désactivé la possibilité de se connecter en tant qu'user.
J'ai appliqué dans les policies les besoins d'accès coté support qui sont ressortis des ateliers avec rdvi et rdvs mais il reste à expérimenter avec le support rdvs avant de basculer toute l'équipe en role support

Next step :

• Basculer les droits nécessaire au support RDVS (@NesserineZarouri et @mekaidmekaid) qui sont accessibles uniquement en super_admin (pour supprimer le rôle de super_admin à terme)
  A expérimenter avec le support. (Issue à créer). Cela permettra de clôturer [SSI] Dissocier les rôles d'administration entre eux #3622
• Renommer le model 'SuperAdmin', je propose 'TeamMember' ou 'SupportMember'

Note pour plus tard : Concernant le contexte des formulaires il y a cette PR en cours coté administrate qui pourra nous servir éventuellement pour adapter les formulaires dans le futur.

[victormours]

Je suis pas sûr de comprendre ce qu'on est en train de faire : pourquoi ajouter toutes ces policy si on veut dire que tout est autorisé ? est-ce que c'est une anticipation sur le rôle support ? Si oui, j'aimerais bien qu'on discute des grandes lignes d'architecture du rôle support parce que je soupçonne qu'on n'ai pas la même vision : j'imaginais qu'on pouvait implémenter le rôle support sans utiliser administrate, ce qui pourrait nous éviter beaucoup de manipulations de données "hors règles métiers" comme ce que fournit administrate.

En faisant une interface rails basique pour le rôle support à la place d'utiliser administrate, on peut ajouter simplement à la main les actions métier que feront les utilisateurs du support (à ma connaissance : lister les agents puis se connecter en tant qu'agent, migrer un agent d'une organisation à une autre, configurer la latitude et longitude d'un lieu, ouvrir un nouveau compte pour une mairie).

[Holist]

Je suis pas sûr de comprendre ce qu'on est en train de faire : pourquoi ajouter toutes ces policy si on veut dire que tout est autorisé ? est-ce que c'est une anticipation sur le rôle support ? Si oui, j'aimerais bien qu'on discute des grandes lignes d'architecture du rôle support parce que je soupçonne qu'on n'ai pas la même vision : j'imaginais qu'on pouvait implémenter le rôle support sans utiliser administrate, ce qui pourrait nous éviter beaucoup de manipulations de données "hors règles métiers" comme ce que fournit administrate.
En faisant une interface rails basique pour le rôle support à la place d'utiliser administrate, on peut ajouter simplement à la main les actions métier que feront les utilisateurs du support (à ma connaissance : lister les agents puis se connecter en tant qu'agent, migrer un agent d'une organisation à une autre, configurer la latitude et longitude d'un lieu, ouvrir un nouveau compte pour une mairie).

Ma proposition est effectivement d'utiliser administrate pour mettre en place ce nouveau niveau d'autorisation "Support".
Via un enum (qui aurait support et super_admin comme valeurs) sur le model super_admin qui serait renommé en admin pour plus de clarté. (?)
L'idée dans cette PR est de préparer le terrain pour la prochaine PR d'implémentation du service support.
Comme je le propose on peut aussi discuter le fait qu'un super_admin puisse créer d'autres super admin depuis administrate et dans ce cas tout ne serait pas autorisé même pour le super_admin.

Après discussions et ateliers avec rdvs et rdvi voici les droits spécifiques qui doivent être implémentés pour le support dans une première version :

• Faire des recherches d'usagers (pour retrouver des informations, notamment leur organisation)
• Se connecter en tant qu'agent.
• Créer un lieu via coordonnées gps (Nesserine)
• Modifier le role et les orgas d'un agent.
• Création de catégorie de motif (et autres potentiels "scripts" métier pour RDVI). C'est un besoin récurrent qui aujourd'hui passe par un développeur rdvi. On pourrait imaginer quelque chose sur le modele de ce qui a été fait pour les mairies (cela créerai également des motifs...)

Etant donné que administrate nous offre déjà une structure (dashboards, vues, implémentation très simple d'autorisations et de scopes avec pundit comme on peut le voir ici, bon niveau de personnalisation comme pour les mairies et possibilité d'ajouter des formulaires avec une logique métier et/ou support dédiée...) je trouve pertinent de garder ce système.
Concernant le besoin il s'agit d'un accès support pour 4 membres de l'équipe rdvi afin de limiter le nombre de super_admins.
L'idée pour une v2 est également de voir dans le temps si ce rôle de support sera utilisable en l'état ou avec d'autres ajouts d'autorisation peut être (Lesquels ?). Avec ce système on pourra tester des choses facilement pour l'équipe support rdvs en modifiant simplement les règles d'autorisation.
Concernant les règles métiers, je partage tes inquiétudes d'une incohérence entre les règles métiers de l'app et de administrate mais je pense que c'est possible de justement réutiliser nos règles au cas par cas pour le support (via les concerns, les services...) quand c'est nécessaire dans administrate (mais également de passer outre pour certains cas spécifique).

[victormours]

D'accord, merci pour les clarifications !

Dans ce cas, je vois une autre direction intéressante : est-ce que le rôle superadmin a encore des raisons d'exister si le rôle support répond aux cas d'usages qui sont listés ici ? J'ai l'impression que non
Du coup, on pourrait implémenter le rôle support en réduisant le nombre de choses qui sont faisables via le super admin (ce qui est encore mieux en train de sécurité). Ces changements passeraient beaucoup par une réduction des ressources déclarées comme accessibles dans app/dashboards/*.rb.

Pour ce qui est des policy, j'ai une petite réticence à ajouter beaucoup de code mort sans avoir encore de cas d'usage, je préfèrerais qu'on attende d'avoir une implémentation où elles font vraiment quelque chose (c'est toujours bien d'appliquer yagni).

[victormours]

🎉 Trop bien ! Merci pour toutes les mises à jour, c'est beaucoup mieux comme ça.
J'ai quelques suggestions de naming/règles métier, mais rien de forcément bloquant pour shipper