Fonctionnalité ADULLACT à venir : "Admin de groupe"
auteurs : @adullact + @fvantomme (synbioz)
Administrateur de groupe : expression de besoin & considérations techniques
Contexte
Démarches Simplifiées (DS) dispose d'une gestion de profils offrant à chacun d'eux des capacités d'action distinctes au sein de l'application.
Les profils DS sont les suivants :
- Administrateur : création et publication de formulaires
- Instructeur : instruction de dossiers
- Expert : consultant sur un ou plusieurs dossiers
- Usager : dépôt et suivi de dossiers
Plus un profil spécial, « super-admin », dédié à l'administration technique de l'instance (ex: feature flags)
Il est possible qu’un compte soit lié à différents profils. Par exemple, un administrateur peut aussi être usager ou instructeur sur des procédures différentes.
Actuellement
Les profils existants ne permettent pas de gérer les structures regroupant plusieurs collectivités (ex: une métropole, une communauté de communes), devant gérer ses entités, sans les mélanger avec d'autres. C'est indispensable dans un contexte de mutualisation.
Préambule sur les mutualisants
- Groupement (mutualisant) : Agglomération, Métropole
- Exemple :
- Agglomération de Montpellier ---> 1 adhésion = 30 villes = 30 comptes sur chaque service ADULLACT (DS, Asqatsun, …)
- RECIA ---> 350 adhérents = donc potentiellement 350 comptes DS à créer
- Ternum BFC (Bourgogne Franche Comté) ----> 1200 adhérents = donc potentiellement 1200 comptes DS à créer
- Habituellement : à l'ADULLACT pour chaque service, quand c'est possible nous déléguons la création des comptes à chaque groupement
Comportement attendu
Il faudrait disposer d'un 5e profil : admin de groupe.
L'administrateur de groupe administre plusieurs entités et est en mesure de créer et gérer les droits de personnes ayant accès à ces entités ; soit comme administrateur de démarche (création de formulaire et gestion des profils), soit comme instructeur.
Analyse fonctionnelle & technique
Feature flag
Il est important de conserver à l'esprit que notre contribution intéressa certainement d'autres instances mutualisées de DS, mais vraisemblablement pas les instances dédiées. Aussi, il serait pertinent de placer l'ensemble de ces développements sous un paramètre de configuration feature flag (activé / désactivé).
Si la fonctionnalité "admin de groupe" est activée, alors un profil éponyme sera disponible sur l'instance.
Gestion des admins de groupe
Seul un super-admin a la possibilité de créer, lister, modifier ou supprimer (CRUD) des admins de groupe.
Écrans
Liste des admins de groupe
Formulaire de création d'un admin de groupe
Dans la liste des administrateurs, afficher l'admin de groupe père s'il existe
Suppression
La suppression d'un admin de groupe ne doit être possible que si tous ses administrateurs fils sont supprimés.
Note : Désactiver les administrateurs fils n'est pas suffisant pour autoriser la suppression de leur admin de groupe. En effet, si l'on supprime ce dernier et qu'on réactive l'un des administrateurs, alors toute notion d'appartenance à un groupe serait oubliée.
Gestion des administrateurs
Un admin de groupe doit pouvoir créer, lister, modifier et supprimer (CRUD) des administrateurs, sans pour autant être super-admin. Ses prérogatives se limitent à la seule gestion des administrateurs.
Note : Un admin de groupe ne doit pas pouvoir créer d'autres admins de groupe.
Écrans
liste les administrateurs créés par l'admin de groupe
Note: les administrateurs créés par un autre admin de groupe ne sont pas listés.
formulaire d'ajout d'administrateur
Création
Tout administrateur créé par un admin de groupe lui sera directement rattaché.
Liste
Un admin de groupe ne visualisera que la liste des administrateurs qu'il a lui-même créé.
Mise à jour
Un admin de groupe ne pourra mettre à jour qu'un administrateur qu'il a lui-même créé.
Suppression
Un admin de groupe ne pourra supprimer qu'un administrateur qu'il a lui-même créé.
La suppression d'un administrateur répondra aux mêmes contraintes qu'aujourd'hui, entendu qu'une procédure ne peut peut se retrouver sans administrateur associé.
# app/models/administrateur.rb
def can_be_deleted?
procedures.all? { |p| p.administrateurs.count > 1 }
end
Filiation
Un administrateur créé par un admin de groupe lui sera directement rattaché pour marquer sa filiation. Il sera donc nécessaire de faire évoluer le modèle Administrateur
comme suit.
class LinkAdministrateurAndAdministrateurDeGroupe < ActiveRecord::Migration[6.1]
def change
add_reference :administrateurs, :administrateur_de_groupe, index: true
add_foreign_key :administrateurs, :administrateurs_de_groupe
end
end
Cela implique la création d'un nouveau modèle AdministrateurDeGroupe
:
class CreateAdministrateursDeGroupe < ActiveRecord::Migration[6.0]
def change
create_table :administrateurs_de_groupe do |t|
t.string :email, null: false
t.boolean :active, default: true, null: false
t.timestamps
t.index ["email"], name: "index_administrateurs_de_groupe_on_email", unique: true
end
end
end
Ce modèle se verra lié à un User
comme c'est le cas pour Administrateur
, Instructeur
et Expert
.
class LinkUserAndAdministrateurDeGroupe < ActiveRecord::Migration[6.1]
def change
add_reference :users, :administrateur_de_groupe, index: true
add_foreign_key :users, :administrateurs_de_groupe
end
end
Barre de navigation
Si l'utilisateur connecté dispose de plusieurs profils, il lui sera possible de basculer sur le profil « admin de groupe » depuis la barre de navigation, comme c'est actuellement le cas pour les autres profils. Ce faisant, chaque action accessible à ce seul profil devra étendre du contrôleur AdministrateursDeGroupe::AdministrateurDeGroupeController
qui s'assurera que l'utilisateur connecté a le niveau de permissions requis.
module AdministrateursDeGroupe
class AdministrateurDeGroupeController < ApplicationController
before_action :authenticate_administrateur_de_groupe!
def nav_bar_profile
:administrateur_de_groupe
end
end
end
Authentification
Lors de son authentification, l'utilisateur sera redirigé vers la page d'accueil de son profil de plus haut niveau, admin de groupe ayant la priorité.
class RootController < ApplicationController
include ApplicationHelper
def index
if administrateur_de_groupe_signed_in?
return redirect_to manager_administrateur_de_groupe_path
if administrateur_signed_in?
return redirect_to admin_procedures_path
elsif instructeur_signed_in?
return redirect_to instructeur_procedures_path
elsif user_signed_in?
return redirect_to dossiers_path
elsif super_admin_signed_in?
return redirect_to manager_root_path
end
@stat = Stat.first
render 'landing'
end
end
One-Time Password (OTP)
L'accès à l'espace manager par un super-admin requiert une authentification via OTP (2FA). Cette forme d'authentification devrait être envisagée également pour les admins de groupe.
Espace Manager
L'espace manager vu par un admin de groupe se verra limité à la seule gestion des administrateurs comme présenté ci-dessus.
Notion de groupe
La terminologie « admin de groupe » implique la notion de groupe. Il est en effet nécessaire de circonscrire les administrateurs créés par un admin de groupe en obligeant ce dernier à les associer à une organisation présente dans une liste d'organisations associées au compte de l'admin de groupe.
Contextes d'utilisation
- Ministère avec la liste de ses services
- ADULLACT pour la gestion des mutualisants et des grosses structures (Conseil Départemental)
- Mutualisant avec son instance DS qui souhaite faire de la délégation auprès de certaines de ses collectivités
- Entreprise souhaitant proposer du DS en mode SaaS, et souhaitant gérer ses différents clients.
Circonscrire les admins de groupe
Le périmètre d'un admin de groupe est défini par une liste d'organisations auxquelles il appartient et auxquelles il peut rattacher les administrateurs qu'il a lui-même créé. Une organisation peut être une collectivité ou un service d'un ministère, par exemple.
La liste des organisations est saisie par le super-admin au moment de la création de l'admin de groupe.
Quand l'admin de groupe crée un administrateur, il doit l'associer à une organisation de la liste. Ainsi :
- une organisation peut être liée à N administrateurs
- un administrateur est lié à une seule organisation
Gestion des organisations
Seul un super-admin a la possibilité de créer, lister, modifier ou supprimer (CRUD) des organisations.
Une organisation est caractérisée par une désignation (ex: Ternum BFC) et une description (ex: Territoires Numériques de Bourgogne Franche-Comté).
Une organisation ne peut-être supprimée que si aucun administrateur ne lui est rattaché.
Un admin de groupe sans organisation sera dans l'incapacité de créer de nouveaux administrateurs.
Remarques & questions
Profil expert
Le profil expert semble bénéficier d'un traitement particulier. Il n'est pas pris en compte dans le mode maintenance :
# app/controllers/application_controller.rb
before_action :reject, if: -> { ENV.fetch("MAINTENANCE_MODE", 'false') == 'true' }
def reject
# ...
[:user, :instructeur, :administrateur].each { |role| sign_out(role) }
flash[:alert] = MAINTENANCE_MESSAGE
redirect_to root_path
# ...
end
Et est absent d'un certain nombre de méthodes :
# app/controllers/application_controller.rb
def current_account
{
administrateur: current_administrateur,
instructeur: current_instructeur,
user: current_user
}.compact
end
private
def set_current_roles
Current.administrateur = current_administrateur
Current.instructeur = current_instructeur
end
def current_user_roles
@current_user_roles ||= begin
roles = [
current_user,
current_instructeur,
current_administrateur,
current_super_admin
].compact.map { |role| role.class.name }
roles.any? ? roles.join(', ') : 'Guest'
end
end
# app/models/current.rb
class Current < ActiveSupport::CurrentAttributes
attribute :instructeur, :administrateur
end
Ce traitement particulier est-il volontaire ? Cela pourrait-il avoir un impact sur la manière dont il nous faudra considérer le cas des admins de groupe ?