Projet

Général

Profil

Development #10075

Organisation de prise en charge des demandes au sein d'un pool d'agents

Ajouté par Brice Mallet il y a environ 8 ans. Mis à jour il y a environ 8 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
-
Version cible:
Début:
24 février 2016
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:

Description

Quand plusieurs agents sont susceptibles de traiter les mêmes demandes (cas typique, les guichets uniques à la façon Alfortville), ceux-ci peuvent être nombreux et ne pas pouvoir communiquer (sur sites différents, là encore cas d'Alfortville), il est alors nécessaire qu'un agent prenant en charge une demande soit certain que celle-ci ne soit pas déjà en cours de traitement par un autre agent (plus rapide;-).

Solution esquissée lors EO Camp marseillais = afficher une alerte :
  • les demandes récemment vues/travaillées par quelqu'un ayant une action possible sur le statut actuel de la demande seraient marquées via un cadenas
  • rafraîchir régulièrement le listing pour avoir les cadenas
  • afficher le cadenas et message "la demande est en cours de traitement par <nom de l'agent>" sur l'écran de traitement de l'agent n°2
  • sur la vue de la demande, si elle est signalée comme lockée pour l'agent et que l'agent quitte la page -> onbeforeunload pour délocker
Possible d'aller plus loin sur contrôle :
  • en plus du haut de page, affichage en bas de page au-dessus de la zone d'action (et clic sur un bouton nécessaire avant d'agir sur les actions si la demande était lockée)
Possible d'autres moyens d'alerte (visualisation) :
  • avoir un bouton 'Passer à la demande suivante' qui ouvrirait la prochaine demande non déjà prise en charge dans ce statut (par rapport au listing et ses critères sur lequel l'agent était). Rq : faire gaffe à sauter les formulaires dont le statut aurait entre temps changé
  • si utilisation préférentielle de la vue globale, afficher directement le cadenas dans cette vue (icône + ligne estompée ?)

Fichiers


Demandes liées

Lié à Publik - Development #9418: Pool de demandes pour aiguillage vers agentsFermé22 décembre 2015

Actions

Révisions associées

Révision 3aeec7ca (diff)
Ajouté par Frédéric Péters il y a environ 8 ans

backoffice: add advisory locking to formdata (#10075)

Historique

#1

Mis à jour par Brice Mallet il y a environ 8 ans

  • Tracker changé de Bug à Project management
  • Description mis à jour (diff)
#2

Mis à jour par Brice Mallet il y a environ 8 ans

  • Description mis à jour (diff)
#4

Mis à jour par Brice Mallet il y a environ 8 ans

#5

Mis à jour par Frédéric Péters il y a environ 8 ans

  • Tracker changé de Project management à Development
  • Projet changé de Publik à w.c.s.
#6

Mis à jour par Frédéric Péters il y a environ 8 ans

  • rafraîchir régulièrement le listing pour avoir les cadenas

Laissé à la discrétion de l'agent, pas de rafraichissement automatique (pour le moment).

  • sur la vue de la demande, si elle est signalée comme lockée pour l'agent et que l'agent quitte la page -> onbeforeunload pour délocker

Le onbeforeunload est trop compliqué. (il faudrait tracker chaque onglet/fenêtre indépendamment, pas tenable).

en plus du haut de page, affichage en bas de page au-dessus de la zone d'action (et clic sur un bouton nécessaire avant d'agir sur les actions si la demande était lockée)

Dans mon patch affichage d'un message uniquement au-dessus de la zone d'action, mais pas de bouton supplémentaire, juste une information.

avoir un bouton 'Passer à la demande suivante' qui ouvrirait la prochaine demande non déjà prise en charge dans ce statut (par rapport au listing et ses critères sur lequel l'agent était). Rq : faire gaffe à sauter les formulaires dont le statut aurait entre temps changé

Hors scope.

#7

Mis à jour par Frédéric Péters il y a environ 8 ans

(à noter que niveau perf j'ai regardé sur nos sites de prod et charger toutes les sessions ça se faisait partout en moins de 0,05 secondes, je suis donc resté au pickle.) (mais c'était un dimanche matin).

#8

Mis à jour par Thomas Noël il y a environ 8 ans

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

en plus du haut de page, affichage en bas de page au-dessus de la zone d'action (et clic sur un bouton nécessaire avant d'agir sur les actions si la demande était lockée)

Dans mon patch affichage d'un message uniquement au-dessus de la zone d'action, mais pas de bouton supplémentaire, juste une information.

Ça serait un argument imparable contre « les agents ne lisent pas l'écran ». Blague à part, je crois que le message n'est pas suffisant pour éviter les fausses manip quand on a 10 demandes à gérer depuis 10 mails reçus, i.e. sans passer par les listings avec les cadenas. Ceci dit, pour une v0, c'est suffisant.

Au passage, comme dans les autres messages de lock, on pourrait afficher la date du lock ?

(sinon je n'ai pas lu le patch attentivement encore)

#9

Mis à jour par Frédéric Péters il y a environ 8 ans

Blague à part, je crois que le message n'est pas suffisant pour éviter les fausses manip quand on a 10 demandes à gérer depuis 10 mails reçus, i.e. sans passer par les listings avec les cadenas. Ceci dit, pour une v0, c'est suffisant.

Oui, et un autre avantage à ne pas afficher le formulaire d'action quand c'est verrouillé c'est qu'on n'a alors pas à ajouter de verrou sur la demande pour cette seconde personne. (j'ai fait le patch avant de lire le ticket)

Au passage, comme dans les autres messages de lock, on pourrait afficher la date du lock ?

Genre la liste des noms d'agents et entre parenthèses la date de verrou de chacun d'eux ?

#10

Mis à jour par Thomas Noël il y a environ 8 ans

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

Blague à part, je crois que le message n'est pas suffisant pour éviter les fausses manip quand on a 10 demandes à gérer depuis 10 mails reçus, i.e. sans passer par les listings avec les cadenas. Ceci dit, pour une v0, c'est suffisant.

Oui, et un autre avantage à ne pas afficher le formulaire d'action quand c'est verrouillé c'est qu'on n'a alors pas à ajouter de verrou sur la demande pour cette seconde personne. (j'ai fait le patch avant de lire le ticket)

Ce qui serait super c'est d'afficher les actions, mais grisées. Et qu'une case à cocher soit présente dans le message (« [ ] débloquer les actions ») si l'agent doit quand même intervenir.

Je me demande dans quelle mesure on pourra ensuite faire en sorte qu'un agent puisse dire "je ne m'occupe plus de cette demande, libérer mon lock" (cas d'usage : j'ai fini ma partie du travail). Peut-être voir au niveau du lien final "retour au listing". (c'est plutôt une idée pour un ticket à venir, après qu'on aura une première version validée)

Au passage, comme dans les autres messages de lock, on pourrait afficher la date du lock ?

Genre la liste des noms d'agents et entre parenthèses la date de verrou de chacun d'eux ?

Yep.

#11

Mis à jour par Frédéric Péters il y a environ 8 ans

Ce qui serait super c'est d'afficher les actions, mais grisées. Et qu'une case à cocher soit présente dans le message (« [ ] débloquer les actions ») si l'agent doit quand même intervenir.

Ce que fait ce nouveau patch, c'est ajouter un lien "unlock actions" derrière le message d'avertissement, un clic dessus affiche le formulaire. (après un reload, cela sans jouer avec du javascript).

#12

Mis à jour par Thomas Noël il y a environ 8 ans

Ack, j'aime bien la logique du truc.

#13

Mis à jour par Frédéric Péters il y a environ 8 ans

  • Statut changé de En cours à Résolu (à déployer)
commit 3aeec7ca786c1b5fa3051029a56e1cb8df91c1c7
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Sun Feb 28 11:58:12 2016 +0100

    backoffice: add advisory locking to formdata (#10075)
#14

Mis à jour par Pierre Cros il y a environ 8 ans

Traductions :

  • Be warned this form is also being looked at by: Thomas Noël (less than 2 minutes ago).=> Attention ! Ce formulaire est actuellement bloqué car consulté par : (il y a moins de 2 min).
  • Unlock actions => Débloquer
#15

Mis à jour par Thomas Noël il y a environ 8 ans

  • Version cible mis à v1.36
#16

Mis à jour par Frédéric Péters il y a environ 8 ans

J'écrivais :

(à noter que niveau perf j'ai regardé sur nos sites de prod et charger toutes les sessions ça se faisait partout en moins de 0,05 secondes, je suis donc resté au pickle.) (mais c'était un dimanche matin).

Je viens de refaire ce test maintenant (fin de matinée d'un jour de semaine), et les résultats sont similaires (le plus long c'est Meyzieu, avec 0,036 secondes).

#17

Mis à jour par Frédéric Péters il y a environ 8 ans

Je viens de pousser ça en plus :

commit f1ed5fbdde80fdcdde4ab8fab06471f3df368c62
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Wed Mar 2 18:23:08 2016 +0100

    style: update colour of infonotice action link

    (blue on another blue was not readable)
#19

Mis à jour par Thomas Noël il y a environ 8 ans

  • Statut changé de Résolu (à déployer) à Fermé

Formats disponibles : Atom PDF