Produits Entr'ouvert » w.c.s.

"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).

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.

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.

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

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.

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

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.

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.

• 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é).

Après nouveau regard posé ici, il s'agit principalement de détourner l'accès à /backoffice/data/, qui doit laisser passer l'agent, laisser à plus bas le contrôle d'accès. Mais on ne veut pour autant pas devoir inspecter toutes les fiches à chaque accès.

Automatic expiration