Project

General

Profile

Autre #66784

fiches : donner accès au *listing* des fiches sans avoir le droit de visualisation aux rôles ayant le droit de création

Added by Benjamin Dauvergne 7 months ago. Updated 7 months ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
29 June 2022
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

C'est pour discuter, un client a posé la question et mon CPF me relance alors je passe la balle ailleurs. Cf. #64899

PS: ce ticket est parfaitement le lieu pour donner un chiffrage, si une idée de réalisation se manifestait.

PS2: donc l'idée c'est qu'on crée des fiches, via le workflow on obtient un droit de visu sur celles qu'on a créé mais on a pas accès au listing et si on donne accès au listing via le rôle visualisation, on voit tout. L'idée serait peut-être aussi sans parler de rôle de pouvoir voir le listing si on a le moindre droit sur une fiche, là visiblement il faut absolument avoir un rôle marqué "Visualisation"

History

#2

Updated by Benjamin Dauvergne 7 months ago

  • Description updated (diff)
#3

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

"fiches : ne pas donner des droits de visualisation au rôle de création"

C'est déjà le cas.

Le ticket lié demande l'inverse, a priori, je n'ai pas tout relu.

J'y notais le contexte :

(dans le contexte des demandes mais ça vient de là), l'agent qui saisit la demande pour un usager ne doit pas forcément gagner accès à la liste de toutes les demandes.

Perso la situation actuelle de code et comportement identique entre demandes et fiches me va bien; et il n'est vraiment pas compliqué de donner un accès en lecture si souhaité (il suffit de mettre le rôle dans une fonction de traitement).

#4

Updated by Benjamin Dauvergne 7 months ago

  • Subject changed from fiches : ne pas donner des droits de visualisation au rôle de création to fiches : donner accès au *listing* des fiches sans avoir le droit de visualisation aux rôles ayant le droit de création
  • Description updated (diff)
#5

Updated by Benjamin Dauvergne 7 months ago

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

(dans le contexte des demandes mais ça vient de là), l'agent qui saisit la demande pour un usager ne doit pas forcément gagner accès à la liste de toutes les demandes.

J'ai du relire aussi vu que visiblement je ne comprenais pas la question et donc revoilà ma traduction du truc.

#6

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

J'écrivais :

Perso la situation actuelle de code et comportement identique entre demandes et fiches me va bien; et il n'est vraiment pas compliqué de donner un accès en lecture si souhaité (il suffit de mettre le rôle dans une fonction de traitement).

Et je rejetterais volontiers sur cette base, sauf élément nouveau.

#7

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

Zappé la modif au sujet pour demander autre chose; ce que ça pointe c'est pour moi l'absence d'une double entrée (saisie/traitement) pour le cas des fiches.

Il me semble que ça pourrait se résoudre en modifiant la page des fiches (/backoffice/data/), pour que les liens apparaissent (mais pointant vers la création) pour les rôles qui n'auraient que la création comme accès. (plutôt qu'en les envoyant sur un écran de traitement avec rien à traiter).

#8

Updated by Mikaël Ates 7 months ago

Dans la description du ticket :

Est-il normal de ne pas pouvoir accéder aux listings de fiches lorsqu'on a uniquement le rôle de création dessus ?
...
Il ne peut donc pas accéder au bouton "Ajouter" pour créer une fiche

(Je n'ai pas vérifié que c'était effectivement le cas mais Benjamin a confirmé.)

La demande c'est donc de donner automatiquement la visualisation des fiches à celui qui a le droit de création afin qu'il puisse accéder au bouton "Ajouter".

Le problème n'est pas que c'est compliqué de donner à celui qui peut créer les fiches le role visualisation en plus du rôle de création, ou qu'on le fasse hériter des deux rôles, ou autre, mais qu'il y ait besoin d'une opération d'administration pour faire ce qui semblerait le plus logique : si on peux ajouter une fiche via le BO, il faut qu'automatiquement que l'on puisse accéder au bouton ajouter, donc que l'on accède au listing.

#9

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

pour faire ce qui semblerait le plus logique : si on peux ajouter une fiche via le BO, il faut qu'automatiquement que l'on puisse accéder au bouton ajouter, donc que l'on accède au listing.

Le logique de donner un accès au tableau de traitement à un agent qui n'a pas de permission de traitement.

Dans ce ticket (au commentaire précédent, pas au milieu d'un historique d'un autre ticket), je propose :

Il me semble que ça pourrait se résoudre en modifiant la page des fiches (/backoffice/data/), pour que les liens apparaissent (mais pointant vers la création) pour les rôles qui n'auraient que la création comme accès. (plutôt qu'en les envoyant sur un écran de traitement avec rien à traiter).

~~

Dans la description du ticket :

(j'encourage les tickets qui n'exigent pas d'aller lire un historique ailleurs.)

#10

Updated by Mikaël Ates 7 months ago

Dans ce ticket (au commentaire précédent, pas au milieu d'un historique d'un autre ticket),

Oui, j'ai rédigé mon message sur base du commentaire qui le précède "Et je rejetterais volontiers sur cette base, sauf élément nouveau." qui a précipité ma réponse sans lire celle qui est arrivée entre temps (c'est l'effet que fait le mot rejetter).

je propose :

Il me semble que ça pourrait se résoudre en modifiant la page des fiches (/backoffice/data/), pour que les liens apparaissent (mais pointant vers la création) pour les rôles qui n'auraient que la création comme accès. (plutôt qu'en les envoyant sur un écran de traitement avec rien à traiter).

Cela me semble très bien.

#11

Updated by Benjamin Dauvergne 7 months ago

Non ergonomiquement c'est nul, il n'est pas normal qu'un lien change de destination sans que ce soit prévisible par l'utilisateur, le fait de faire des parallèle avec le traitement des demandes est trompeur, la cible c'est une application CRUD sur BDD, et ça ne fonctionne pas comme ça en général. De plus une action de traitement est possible: créer une fiche.

Le listing doit s'afficher dans ces 4 cas :
  • on a le rôle de création,
  • celui d'édition
  • celui de visualisation,
  • une action est possible sur une fiche pour un de nos rôles (ou une affectation direct fonction/utilisateur)

Il me semble que seul le premier n'est pas vrai actuellement et c'est ce qu'il faut corriger.


Idéalement le workflow par défaut devrait donner le droit en édition/visualisation au créateur d'une fiche, mais ça clashe peut-être avec les usages où un workflow crée une fiche à la création d'une demande (on aurait comme créateur l'usager), sans ça pour les gens qui ne sont que créateurs par défaut le listing sera toujours vide (mais ça se voit vite et ça se corrige vite en modifiant le workflow pour ajouter une liaison fonction/rôle de Éditeur vers "{{ session_user }}" dans le statut Enregistré).

#12

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

  • Tracker changed from Development to Autre

Il y a des réflexions à mener en parallèle avec l'écran "saisie" qui existe déjà, qui présente les titres des démarches sous forme de liens, qui envoient vers la création. Cet écran doit également évoluer.

Je souhaiterais qu'on ne s'emballe pas ici, qu'on n'aille pas au petit arrangement qui semble immédiat. Je préfère intégrer la demande dans les orientations globales à définir concernant ces écrans.

(et oui ça ne permet pas de fournir un chiffrage immédiat).

Also available in: Atom PDF