Project

General

Profile

Development #14297

Pouvoir faire des stats sur le passage par un statut particulier

Added by Frédéric Péters almost 3 years ago. Updated about 2 months ago.

Status:
Solution proposée
Priority:
Normal
Target version:
-
Start date:
14 Dec 2016
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No

Description

Par exemple j'ai des statuts "Demande acceptée" et "Demande refusée" qui convergent plus tard mais j'aimerais bien pouvoir compter le nombre de demandes acceptées et le nombre de demandes refusées; ou alors pour reprendre un autre exemple à partir du workflow attaché, je voudrais connaitre la part de paiements faits en ligne.

Capture du 2016-12-14 10-58-45.png View (32.2 KB) Frédéric Péters, 14 Dec 2016 10:59 AM

Capture d’écran 2016-12-22 à 13.53.17.png View (385 KB) Frédéric Péters, 22 Dec 2016 01:53 PM

0002-feeder-store-delay-since-receipt_time-in-evolution-t.patch View (6.22 KB) Benjamin Dauvergne, 18 Jan 2019 11:09 PM

0005-make-statistics-on-evolutions-fixes-14297.patch View (4.02 KB) Benjamin Dauvergne, 18 Jan 2019 11:09 PM

0001-tests-fix-indentation.patch View (1.7 KB) Benjamin Dauvergne, 18 Jan 2019 11:09 PM

0003-feeder-add-timetamp-version-of-receipt_time.patch View (2.13 KB) Benjamin Dauvergne, 18 Jan 2019 11:09 PM

0004-add-measure-on-max-delay-before-status-14297.patch View (5.4 KB) Benjamin Dauvergne, 18 Jan 2019 11:09 PM

0004-make-statistics-on-evolutions-fixes-14297.patch View (4.02 KB) Benjamin Dauvergne, 08 Mar 2019 12:26 AM

0003-add-measure-on-max-delay-before-status-14297.patch View (5.58 KB) Benjamin Dauvergne, 08 Mar 2019 12:26 AM

0002-feeder-add-timetamp-version-of-receipt_time.patch View (2.24 KB) Benjamin Dauvergne, 08 Mar 2019 12:26 AM

0001-feeder-store-delay-since-receipt_time-in-evolution-t.patch View (6.27 KB) Benjamin Dauvergne, 08 Mar 2019 12:26 AM

0002-tox.ini-use-environment-tag-to-fix-python-interprete.patch View (736 Bytes) Benjamin Dauvergne, 24 Sep 2019 03:28 PM

0007-tests-wip-add-tests-with-bijoe.patch View (4.99 KB) Benjamin Dauvergne, 24 Sep 2019 03:28 PM

0003-feeder-store-delay-since-receipt_time-in-evolution-t.patch View (6.28 KB) Benjamin Dauvergne, 24 Sep 2019 03:28 PM

0005-add-measure-on-max-delay-before-status-14297.patch View (5.58 KB) Benjamin Dauvergne, 24 Sep 2019 03:28 PM

0001-tests-add-support-for-pg_virtualenv.patch View (3.13 KB) Benjamin Dauvergne, 24 Sep 2019 03:28 PM

0006-make-statistics-on-evolutions-fixes-14297.patch View (4.02 KB) Benjamin Dauvergne, 24 Sep 2019 03:28 PM

0004-feeder-add-timetamp-version-of-receipt_time.patch View (2.24 KB) Benjamin Dauvergne, 24 Sep 2019 03:28 PM

14496
14630

Related issues

Related to BiJoe - Development #29914: Pouvoir déclarer des jointures nécessaires pour une mesure Solution proposée 18 Jan 2019
Related to w.c.s. - Development #36412: api: exposer le statut waitpoint dans le schéma du workflow Solution déployée 24 Sep 2019

History

#1 Updated by Thomas Noël almost 3 years ago

(à noter que c'est déjà possible en posant un champ de traitement, ce qui est relativement pertinent par ailleurs
)

#2 Updated by Frédéric Péters almost 3 years ago

Oui mais plutôt que devoir modifier les workflows pour marquer les points potentiels de stats l'info pouvait être générée automatiquement et systématiquement par wcs-olap (c'était du moins mon idée).

#3 Updated by Thomas Noël almost 3 years ago

Oui oui, je suis juste dans une journée pinaillage.

#4 Updated by Benjamin Dauvergne almost 3 years ago

J'exporte déjà l'historique des évolutions via wcs-olap (pour montpellier qui traite ça via BO derrière), et donc les statuts historisés, mais je ne sais pas comment je pourrai faire ce qui est demandé là avec bijoe et qui demanderait à comprendre le workflow et notamment qu'une demande ne peut pas avoir été à la fois dans le statut 'demande refusée' et 'demande acceptée'. C'est la question de savoir ce qui est additif ou pas, on ne peut grouper les stats que par des domaines additifs (ou disjoints ça dépend d'où on parle), i.e si

nombre(demande refusée OU demande acceptée) = nombre(demande refusée) + nombre(demande acceptée)

Si j'affiche les décomptes regroupés par tous les statuts dans la table des évolutions on va avoir des demandes comptés n fois... On ne pourrait vraiment utiliser cette table que pour du filtrage (ex. "quels sont les demandes qui étaient à un moment en statut 'demande acceptée' ou 'demande refusée' au mois de janvier") pour l'instant tout en groupant par statut des évolutions, mais la lecture du graphique généré doit vraiment se faire en connaissant le workflow pour voir si ça a un sens.

#5 Updated by Frédéric Péters almost 3 years ago

Un bout d'information important zappé dans la description initiale c'est que le souhait (/ un souhait proche), c'est garder l'information chronologique, pour pouvoir dire "tel jour tant de passages par 'demande à valider', tel autre jour tant de passages par 'demande finalisée', etc.").

#6 Updated by Benjamin Dauvergne almost 3 years ago

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

Un bout d'information important zappé dans la description initiale c'est que le souhait (/ un souhait proche), c'est garder l'information chronologique, pour pouvoir dire "tel jour tant de passages par 'demande à valider', tel autre jour tant de passages par 'demande finalisée', etc.").

C'est exactement ce que permettrait le schéma actuel:
- grouper par jour et par statut des évolutions
- filtrer sur demande à valider / demande finalisée

Possible souci expliqué plus haut mais que je reformule: pour un même jour si une demande est passée par "à valider" et "finalisée", elle sera comptée deux fois (donc si on a eu 100 demande traitées ce jour là, la somme des deux statuts fera 101, pas 100).

#7 Updated by Frédéric Péters almost 3 years ago

14630

Possible souci expliqué plus haut mais que je reformule: pour un même jour si une demande est passée par "à valider" et "finalisée", elle sera comptée deux fois (donc si on a eu 100 demande traitées ce jour là, la somme des deux statuts fera 101, pas 100).

Oui, pas de soucis, c'est exactement ça qu'il faut. Capture d'écran attachée pour donner une idée de ce que je produis à Liège.

#8 Updated by Benjamin Dauvergne 10 months ago

  • Assignee set to Benjamin Dauvergne

#9 Updated by Benjamin Dauvergne 10 months ago

  • Related to Development #29914: Pouvoir déclarer des jointures nécessaires pour une mesure added

#12 Updated by Benjamin Dauvergne 8 months ago

  • Status changed from Solution proposée to En cours

#13 Updated by Benjamin Dauvergne about 2 months ago

En gros l'idée c'est de stocker le délai entre le début d'un formulaire et n'importe quelle évolution, ensuite ça peut-être utiliser par #29914 pour faire une mesure sur une colonne de la table evolution (la colonne délai) en filtrant/groupant par statut ; mais la jointure doit être faite adéquatement, comme on veut qu'un délai par statut par exemple faudra garder que la première/dernière évolution pour chaque formdata (et ça c'est un boulot pour #29914 de voir comment on peut faire, donner des exemples de SQL pour cela).

Pour les simples décompte ça va marcher tout seul, modulor la remarque plus haut que j'ai faite en #14297#note-6:

Possible souci expliqué plus haut mais que je reformule: pour un même jour si une demande est passée par "à valider" et "finalisée", elle sera comptée deux fois (donc si on a eu 100 demande traitées ce jour là, la somme des deux statuts fera 101, pas 100).

#15 Updated by Benjamin Dauvergne about 2 months ago

Pour le calcul du délai unique par statut pour un formdata je propose d'ajouter les deux vues suivantes pour chaque table d'évolution :

  • délai au premier passage
# view evolution_<slug>_first_time
SELECT distinct on (formdata_id, status_id) * FROM evolution ORDER BY formdata_id, status_id, time
  • délai au dernier passage
# view evolution_<slug>_last_time
SELECT distinct on (formdata_id, status_id) * FROM evolution ORDER BY formdata_id, status_id, time DESC

ou alors changer complètement le chargement de la table d'evolution pour ne garder que les evolutions si le statut n'a pas encore été vu (uniquement premier passage).

#16 Updated by Frédéric Péters about 2 months ago

Tant qu'à être là-dessus, c'est peut-être important de noter dès maintenant que souvent on ne sera pas intéressé par le temps entre le premier statut et un autre, parce que le premier statut sera un truc genre "attente de paiement", que la vraie question portera sur le temps de traitement par l'agent, qui commence plus loin.

Du coup en stat parallèle, par statut, avoir le temps du statut vers le premier statut final rencontré. ?

#17 Updated by Benjamin Dauvergne about 2 months ago

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

Tant qu'à être là-dessus, c'est peut-être important de noter dès maintenant que souvent on ne sera pas intéressé par le temps entre le premier statut et un autre, parce que le premier statut sera un truc genre "attente de paiement", que la vraie question portera sur le temps de traitement par l'agent, qui commence plus loin.

Du coup en stat parallèle, par statut, avoir le temps du statut vers le premier statut final rencontré. ?

Est-ce qu'il ne faudrait pour se faire exporter le statut "waitpoint" d'un "statut" dans le schéma ?

Et donc ça donnerait delay_from_first_waitpoint / delay_to_first_endpoint :
  • construire evolution en gardant qu'une ligne par statut (la première fois qu'on y arrive)
  • pour chaque ligne calculer le délai depuis le premier waitpoint (delay_from_first_waitpoint) et jusqu'au premier statut terminal (delay_to_first_endpoint)

#18 Updated by Frédéric Péters about 2 months ago

Du coup en stat parallèle, par statut, avoir le temps du statut vers le premier statut final rencontré. ?

Est-ce qu'il ne faudrait pour se faire exporter le statut "waitpoint" d'un "statut" dans le schéma ?

Peut-être qu'on peut en effet uniquement avoir des infos sur les (temps de) trajets entre certains statuts. (au total donc début, waitpoints, endpoints)

Et donc ça donnerait delay_from_first_waitpoint / delay_to_first_endpoint :

Parce que l'attente du paiement de l'usager c'est un waitpoint, à mon avis first_waitpoint ça ne tient pas.

#19 Updated by Benjamin Dauvergne about 2 months ago

  • Related to Development #36412: api: exposer le statut waitpoint dans le schéma du workflow added

Also available in: Atom PDF