Produits Entr'ouvert » w.c.s.

Cf les échanges dans #32607.

N'éclairent pas particulièrement, tu peux en faire une synthèse ?

Olap fait appel à /api/forms/<slug>/list?anonymise&full=on pour récuperer des batchs de données de formulaires et se base sur le bout {"workflow": {"status": "...", "name": "..."}} pour determiner le statut dans lequel se trouve la demande.

Or cette section remonte le dernier statut visible à un utilisateur. Aucun utilisateur n'est passé dans la requete faite par olap, donc c'est le statut sans visibilité réglée qui est remonté.

Pourtant dans la liste des evolutions tous les statuts, sans prise en compte de la visibilité, sont remontés.

Il y a donc 2 choses, à mon avis:

1. la liste des evolutions doit tenir compte de la visibilité des statuts pour être en cohérence avec le dernier statut.
2. si anonymise est dans la querystring on devrait retourner le statut en cours de la demande indifféremment de sa visibilité.

donc c'est le statut sans visibilité réglée qui est remonté.

Mais "sans visibilité" c'est peut-être aussi souvent "statut technique évitons d'exposer ça à l'usager" que "statut fonctionne avec du sens pour les agents", et dans les statistiques, du coup, on n'a pas vraiment envie des premiers, il me semble, ce qui expliquerait le comportement, que je ne trouve pas délirant.

si anonymise est dans la querystring on devrait retourner le statut en cours de la demande indifféremment de sa visibilité.

Détail, à voir si on décide vraiment de changer les choses ici, mais ça va commencer à faire perdre son sens au nom de cette option; si sa définition c'est "whatever pour wcs-olap", renommons-la (→ internal-wcs-olap-export=true) ?

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

donc c'est le statut sans visibilité réglée qui est remonté.

Mais "sans visibilité" c'est peut-être aussi souvent "statut technique évitons d'exposer ça à l'usager" que "statut fonctionne avec du sens pour les agents", et dans les statistiques, du coup, on n'a pas vraiment envie des premiers, il me semble, ce qui expliquerait le comportement, que je ne trouve pas délirant.

Moi non plus. Mais dans ce cas on devrait aussi filtrer les statuts par visibilité dans l'evolution de la demande, non?

Ou bien on n'y touche pas, et c'est à wcs-olap de se baser sur l'évolution pour prendre le vrai dernier statut. Dans ce cas le sujet du anonymise tombe à l'eau.

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

si anonymise est dans la querystring on devrait retourner le statut en cours de la demande indifféremment de sa visibilité.

Détail, à voir si on décide vraiment de changer les choses ici, mais ça va commencer à faire perdre son sens au nom de cette option; si sa définition c'est "whatever pour wcs-olap", renommons-la (→ internal-wcs-olap-export=true) ?

Que ce soit clair il n'y pas de rapport entre l'anonymisation et la visibilité/technicité des statuts, c'est totalement othogonal; donc les deux choix sont valables (visible ou pas quand anonymisé). Mais si ça reste caché il faut les cacher aussi du schéma (ou au moins exposer cette information de invisibilité/technicité du statut dans le schéma pour que wcs-olap puisse ne pas les prendre en compte). Voilà le choix :
1. afficher le vrai statut
2. renseigner dans le schéma l'invisibilité des statuts pour que wcs-olap puisse en tenir compte (ou les cacher ça supprime tout boulot dans wcs-olap)

Personnellement je vote 1. les statuts technique on voudra faire des statistiques dessus, c'est certain.

Benjamin Dauvergne a écrit :

Que ce soit clair il n'y pas de rapport entre l'anonymisation et la visibilité/technicité des statuts, c'est totalement othogonal; donc les deux choix sont valables (visible ou pas quand anonymisé). Mais si ça reste caché il faut les cacher aussi du schéma (ou au moins exposer cette information de invisibilité/technicité du statut dans le schéma pour que wcs-olap puisse ne pas les prendre en compte).

On veut voir tous les statuts dans bijoe, on ne doit pas les cacher du schéma.
Donc je pense que ta première proposition est la bonne. On ne passe par par cette API pour afficher les demandes de l'usager, dans laquelle ont doit prendre en compte la visibilité de la demande.

Serghei Mihai a écrit :

Pourtant dans la liste des evolutions tous les statuts, sans prise en compte de la visibilité, sont remontés.

Je précise que pour wcs-olap pour l'instant les évolutions n'ont pas d'importance (on les importe mais aucune statistiques n'est possible dessus pour l'instant). C'est vraiment le statut actuel que tout le monde voit, le souci ici c'est que le schéma remonte tous les statuts et pas la demande; le client CD06 veut des statistiques sur les statuts cachés. C'est tout à fait compréhensible qu'un truc caché au demandeur puisse avoir une importance interne en terme de statistiques.

Il va y avoir #50294; je serais pour fermer ici vu l'effort de lectures qui est demandé pour voir à quoi ça correspond.

De mon coté pas du tout compris pourquoi ça avait finis dans une demande de modif d'API de wcs, ça l'air de se régler assez simplement dans wcs-olap (mais je loupe peut-être quelque chose).

diff --git a/wcs_olap/feeder.py b/wcs_olap/feeder.py
index 5a76b49..8f47d95 100644
--- a/wcs_olap/feeder.py
+++ b/wcs_olap/feeder.py
@@ -793,7 +793,7 @@ class WcsFormdefFeeder(object):
             # ignore formdata without status
             if data.workflow.status:
                 status_id = data.workflow.status.id
-            elif data.evolution:
+            if data.evolution:
                 for evolution in reversed(data.evolution):
                     if evolution.status:
                         status_id = evolution.status