Project

General

Profile

Support #67751

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

Added by Mikaël Ates about 1 year ago. Updated 3 months ago.

Status:
Fermé
Priority:
Normal
Category:
-
Target version:
-
Start date:
27 July 2022
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No
Club:
No

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 ».


Related issues

Related to 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 April 2023

Actions

History

#3

Updated by Brice Mallet 8 months ago

  • Assignee set to Paul Marillonnet
#4

Updated by Paul Marillonnet 6 months ago

  • Status changed from Nouveau to En cours
#7

Updated by Paul Marillonnet 5 months ago

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

Updated by Paul Marillonnet 5 months ago

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

Updated by Frédéric Péters 5 months ago

· 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

Updated by Paul Marillonnet 5 months ago

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

Updated by Paul Marillonnet 5 months ago

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

Updated by Mikaël Ates 3 months ago

  • Status changed from En cours to Solution déployée

C'est fait.

#13

Updated by Transition automatique about 1 month ago

Automatic expiration

Also available in: Atom PDF