Produits Entr'ouvert » OLAP / Business Intelligence pour Publik

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

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

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

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.

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

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

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

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

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é. ?

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 ?

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

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.