Projet

Général

Profil

Support #67751

Approvisionner les rôles dans wcs sans la permission « Backoffice »

Ajouté par Mikaël Ates (de retour le 29 avril) il y a plus d'un an. Mis à jour il y a 10 mois.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
27 juillet 2022
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non
Club:
Non

Description

Les rôles « métiers » sont désormais couramment utilisés dans wcs pour gérer l'affichage des fiches et les accès aux actions en frontoffice via leur association à des fonctions. Cela est fait par exemple sur le projet « Personnes Morales ». Voir https://dev.entrouvert.org/projects/publik-personnes-morales/wiki#Mise-en-%C5%93uvre pour une explication du pourquoi et du comment.

Or, si l'usager dispose au moins d'un rôle avec la permission « Backoffice », la vue des demandes est donnée dans le backoffice de wcs et non sur le frontoffice de wcs. C'est par exemple le cas lorsque l'usager clique sur une demande dans les cellules « Demandes de l'usager » et « Demandes à traiter ».

Les usagers du front office ne devraient pas être aussi des usagers du backoffice. Ainsi, les usagers avec les rôles destinés à un usage en frontoffice ne devraient pas avoir de rôles avec un accès « Backoffice ».

Lorsqu'un rôle est créé dans authentic, il est automatiquement approvisionné dans wcs avec la permission « Backoffice ». Il est aujourd'hui possible de décocher manuellement cette permission. Cependant, cela n'est pas adapté pour aux rôles créés automatiquement. C'est le cas par exemple des « Personnes Morales » où dès l'ajout d'une personne morale, plusieurs rôles sont créés automatiquement.

Il est aussi possible actuellement d'appliquer un contournement qui est de créer dans authentic des rôles commençant par "_" et d'ajouter un setting HOBO_PROVISION_ROLE_PREFIXES autorisant leur approvisionnement dans wcs. Dans ce cas, les rôles sont créés sans la permission « Backoffice ». Cependant, ce fonctionnement n'est pas souhaitable pour une diffusion à tout utilisateur, sur toute instance, d'une application faisant appel à ce type de rôles, un socle de base Personne Morales par exemple.

La pratique actuelle lors de la mise en oeuvre d'une instance consiste à :
  • Créer un rôle « Agent » qui donne l'accès au portail agent.
  • Créer un rôle « Administrateur fonctionnel » avec toutes les permissions wcs (Sauf « Utilisateurs » et « Roles »)

Puis, lors de l'exploitation, de donner à tous les rôles métiers dédiés aux agents le rôle Agent pour ainsi donner l'accès au portail agent.

Si les rôles étaient créés dans wcs sans l'accès « Backoffice », il suffirait pour les CPF d'adapter la pratique de mise en oeuvre en ajoutant uniquement la permission « Backoffice » au rôle Agent.

L'approvisionnement des rôles pourrait donc changer pour que les rôles soient approvisionnés dans wcs sans la permission « Backoffice ».


Demandes liées

Lié à w.c.s. - Development #76756: hobo_notify : faire que le provisionning d’un rôle lui interdise par défaut l’accès au BOFermé18 avril 2023

Actions

Historique

#3

Mis à jour par Brice Mallet il y a plus d'un an

  • Assigné à mis à Paul Marillonnet
#4

Mis à jour par Paul Marillonnet il y a environ un an

  • Statut changé de Nouveau à En cours
#7

Mis à jour par Paul Marillonnet il y a environ un an

Et donc une idée de ce que pourrait être un plan, proposant une de rôles qui soit indépendante de la forme du slug de ceux-ci :
· ajouter dans authentic un flag sur le modèle de rôle, genre “end_users_only” ;
· modifier en conséquence les modèles de rôles dans les briques concernées par le provisionning de rôles ;
· modifier l’api des rôles pour permettre de poser ce flag à la création d’un rôle ;
· modifier la partie hobo agent authentic pour ajouter ce flag au provisionning ;
· modifier les hobo agents des briques concernées pour récupérer ce flag, dans w.c.s en particulier réer le rôle sans la permision BO quand c’est le cas ;
· ajouter les éventuels changements de visibilité dans les briques, exemple #76735 côté combo pour éviter de se manger des listes de rôles à rallonge ;
· déprécier le setting HOBO_PROVISION_ROLE_PREFIXES.

#8

Mis à jour par Paul Marillonnet il y a environ un an

Le plan alternatif, bien plus simple :
· modifier la partie w.c.s. cliente du provisionning pour que tous les rôles soient créés sans la permission d’accès au BO.

Ça demande une analyse de l’existant, voir ce que ça pourrait casser, et last but not least ça veut aussi dire tirer une croix sur #76735, ce qui pourrait devenir un problème à terme.

#9

Mis à jour par Frédéric Péters il y a environ un an

· modifier la partie w.c.s. cliente du provisionning pour que tous les rôles soient créés sans la permission d’accès au BO.

C'est à faire de toute façon, parce que la situation présente donne trop facilement la possibilité de créer un accès backoffice par erreur.

Ça demande une analyse de l’existant

Qui peut être assez sommaire, le risque étant qu'un agent n'ait pas accès et la résolution étant alors facile et gérable en autonomie par la collectivité en ajoutant manuellement l'agent au rôle adéquat, en attendant modification du workflow pour y automatiser cette action.

#10

Mis à jour par Paul Marillonnet il y a environ un an

  • Lié à Development #76756: hobo_notify : faire que le provisionning d’un rôle lui interdise par défaut l’accès au BO ajouté
#11

Mis à jour par Paul Marillonnet il y a environ un an

Frédéric Péters a écrit :

· modifier la partie w.c.s. cliente du provisionning pour que tous les rôles soient créés sans la permission d’accès au BO.

C'est à faire de toute façon, parce que la situation présente donne trop facilement la possibilité de créer un accès backoffice par erreur.

Ça demande une analyse de l’existant

Qui peut être assez sommaire, le risque étant qu'un agent n'ait pas accès et la résolution étant alors facile et gérable en autonomie par la collectivité en ajoutant manuellement l'agent au rôle adéquat, en attendant modification du workflow pour y automatiser cette action.

Bon, sans prise de tête j’ai tapé une branche dans https://git.entrouvert.org/entrouvert/wcs/pulls/248/files qui n’aura d’effet que sur les rôles nouvellement créés, sans incidence donc sur les rôles déjà existants.

#12

Mis à jour par Mikaël Ates (de retour le 29 avril) il y a 10 mois

  • Statut changé de En cours à Solution déployée

C'est fait.

#13

Mis à jour par Transition automatique il y a 8 mois

Automatic expiration

Formats disponibles : Atom PDF