Project

General

Profile

Development #36887

api: exposer le statut de la demande indifférement de sa visiblité quand anonymise=True

Added by Serghei Mihai 4 months ago. Updated 4 months ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
14 Oct 2019
Due date:
% Done:

0%

Patch proposed:
No
Planning:
No

Description

Cf les échanges dans #32607.


Related issues

Related to OLAP / Businesse Intelligence pour Publik - Development #32607: Se baser sur l'évolution d'une demande pour determiner le statut en cours de la demande Nouveau 24 Apr 2019

History

#1 Updated by Serghei Mihai 4 months ago

  • Related to Development #32607: Se baser sur l'évolution d'une demande pour determiner le statut en cours de la demande added

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

Cf les échanges dans #32607.

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

#3 Updated by Serghei Mihai 4 months ago

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

#4 Updated by Frédéric Péters 4 months ago

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

#5 Updated by Serghei Mihai 4 months ago

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.

#6 Updated by Benjamin Dauvergne 4 months ago

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.

#7 Updated by Serghei Mihai 4 months ago

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.

Also available in: Atom PDF