Produits Entr'ouvert » w.c.s.

Le plan pour ce développement tel qu'envisagé par Fred :

"Filtrer sur l'agent qui a fait la saisie (#42103), c'est pas trop compliqué mais un peu chiant différentes directions possibles, et donc faut guider (vite fait et sur le moment : passer l'attribut submission_context de la db en jsonb, et sans doute modifier la classe "criteria" Equal pour gérer ça) (mais on pourrait aussi se dire qu'on veut ça de manière nettement structurée et simple d'accès et en faire un champ dédié dans la table, juste là, j'aime moins)."

• migration: déplacement de formdata.submission_context['agent_id'] vers sa propre colonne backoffice_submission_agent_id
• modification à l'API de listing: ajout d'une paramètre filter-agent-uuid / filter-agent-id : en cas d'uuid faut convertir vers l'id depuis la base des utilisateurs

¹ on devrait toujours viser à structurer quand on peut.

Taper deux plans différents rend un ticket irréalisable.

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

Taper deux plans différents rend un ticket irréalisable.

Je peux enlever le tien ou tu y tiens ?

• ajout d'une migration : conversion de submission_context en JSONB
• modification au critère "Equal" : gérer les colonnes JSONB (voir comment désigner un sous-champ JSONB via le paramètre attribute, passer une liste comme chemin ? utiliser la syntaxe Django à base double underscore ? Fred dira)
• modification à l'API de listing: ajout d'une paramètre filter-agent-uuid / filter-agent-id : en cas d'uuid faut convertir vers l'id depuis la base des utilisateurs via .get_users_with_name_identifier()

Ignorer l'autre plan.

Comme noté explicitement, j'aime moins l'idée d'en sortir les infos pour faire des colonnes dédiées.

A noter que cette évolution de filtrage selon agent-uuid / agent-id pourrait permettre une API « dernières demandes saisies par l'agent xxx », afin de construire sur le portail agent une cellule « les dernières demandes que j'ai saisies » très utiles à un agent d'accueil.

Je ne me prononce pas sur "requêtes sur le jsonb" versus "colonne dédiée", mais je note qu'il serait bien d'avoir cette colonne "backoffice_submission_agent_id" dans la vue globale et j'ai donc l'impression que le plan "colonne dédiée" trouve ici un écho.

J'avoue que je suis pas sûr du truc au niveau fonctionnel. Pour moi :

• Soit l'agent qui a saisi a le droit de voir la demande (parce qu'elle fait partie de la famille de téléservice pour laquelle il a un droit de traitement), on lui donne une fonction dans le traitement, on la lui retire lorsque la demande passe dans un statut où on ne souhaite plus qu'il la voit.

• Soit l'agent qui a saisi n'a pas le droit de voir la demande et on est pas dans les clous en lui donnant cet accès. C'est une chose de saisir, et de pouvoir vérifier que tout s'est bien déroulé. S'en est une autre de pouvoir regarder la demande plusieurs heures/jours après la saisie, ça nécessite un droit de traitement.

De mon côté, avec les gabarits du résumé, il me semble que j'arrive à mettre l'info nécessaire aux agents d'accueil, dans leurs listings.

Mais en relisant je me dis qu'on ne parle que d'accès au listing et pas à la demande, donc vous pouvez m'oublier.

Thomas Noël a écrit :

A noter que cette évolution de filtrage selon agent-uuid / agent-id pourrait permettre une API « dernières demandes saisies par l'agent xxx », afin de construire sur le portail agent une cellule « les dernières demandes que j'ai saisies » très utiles à un agent d'accueil.

Je ne me prononce pas sur "requêtes sur le jsonb" versus "colonne dédiée", mais je note qu'il serait bien d'avoir cette colonne "backoffice_submission_agent_id" dans la vue globale et j'ai donc l'impression que le plan "colonne dédiée" trouve ici un écho.

Dans le thread sur la liste travailleur je suggérais de donner un accès à la demande sur la base de cette colonne, mais je ne suis pas entré dans les détails. Ce serait un accès en frontoffice et pour une durée limitée, disons quelques heures à partir de la soumission (ça pourrait se faire dans FormData.is_submitter(user)).

Benjamin Dauvergne a écrit :

Thomas Noël a écrit :

A noter que cette évolution de filtrage selon agent-uuid / agent-id pourrait permettre une API « dernières demandes saisies par l'agent xxx », afin de construire sur le portail agent une cellule « les dernières demandes que j'ai saisies » très utiles à un agent d'accueil.

Je ne me prononce pas sur "requêtes sur le jsonb" versus "colonne dédiée", mais je note qu'il serait bien d'avoir cette colonne "backoffice_submission_agent_id" dans la vue globale et j'ai donc l'impression que le plan "colonne dédiée" trouve ici un écho.

Dans le thread sur la liste travailleur je suggérais de donner un accès à la demande sur la base de cette colonne, mais je ne suis pas entré dans les détails. Ce serait un accès en frontoffice et pour une durée limitée, disons quelques heures à partir de la soumission (ça pourrait se faire dans FormData.is_submitter(user)).

Pour moi, non, pour ça on devrait éviter d'inventer : l'accès à l'info "nom de la demande + résumé + statut" suffit (comme dit Pierre plus haut, "le listing"). C'est ce qu'on fait déjà au niveau de la recherche ou de la vue par usager. Le fait qu'un agent a soumis une demande ne lui donne pas explicitement de droit pour aller voir ce qu'elle est devenue, même dans les premières heures, parce que "on sait jamais". Si l'agent doit pouvoir voir la demande, alors on lui donne explicitement un rôle pour cela, et voilà.

Thomas Noël a écrit :

Pour moi, non, pour ça on devrait éviter d'inventer : l'accès à l'info "nom de la demande + résumé + statut" suffit (comme dit Pierre plus haut, "le listing"). C'est ce qu'on fait déjà au niveau de la recherche ou de la vue par usager. Le fait qu'un agent a soumis une demande ne lui donne pas explicitement de droit pour aller voir ce qu'elle est devenue, même dans les premières heures, parce que "on sait jamais". Si l'agent doit pouvoir voir la demande, alors on lui donne explicitement un rôle pour cela, et voilà.

Ok, n'en discutons plus ici, je voulais juste détailler mon idée.

Mon besoin à l'origine de ce ticket c'est pour des agents qui font de la saisie et du traitement, et il est toujours valable. La discussion devrait se tenir ailleurs pour laisser ce ticket développement voir le jour.

J'ai donc ajouté une donnée de traitement avec pour identifiant gestionnaire définie dans le premier statut avec {{ form_submission_agent_nameid }} et le listing est appelé avec ?filter-gestionnaire=<uuid de l'agent> (#7115, #42258).

Ça répond à mon besoin mais le problème c'est que ça saute au premier rafraîchissement automatique du listing.

Il y a eu, depuis la mise en oeuvre du filtrage avec une donnée de traitement décrit en note 20, le développement #45072. Mais je ne suis pas parvenu à le mettre en oeuvre. Comment est-ce que je peux l'utiliser pour ce cas d'usage ?

Après trois jours déjà faut me rappeler de quoi on parle, donc après sept mois n'en parlons pas. Tu peux décrire ton cas d'usage et ce que tu as fait et ce que tu attendais et ce qui s'est passé à la place ?

Je souhaite envoyer un agent sur la vue listing et que celle-ci soit filtrée sur les demandes qu'il a saisies.
Actuellement je mets dans une donnée de traitement nommée gestionnaire {{ form_submission_agent_nameid }} et j'affiche à l'agent un lien sur la vue listing avec ?filter-gestionnaire=<son uuid>.

Je préfèrerais basculer sur une prise en charge native, je proposais pour cela un filtre filter-agent-author-uuid.
Avec un peu plus de recul, il y a une colonne « Saisie par » dans les colonnes, et on pourrait avoir un critère de filtrage sur ce même champs.
Peut-être alors ce critère de filtrage pourrait être prérempli avec un champs fourni via l'api, par exemple filter-agent-author-uuid.

#45072 a apporté des choses mais je ne sais pas précisément quoi ni ça va dans cette direction.

Tu veux #45080 et utiliser filter-submission-agent-uuid, il me semble.