Project

General

Profile

Bug #29588

Via l'API et en utilisant un utilisateur destinataire du formulaire, je ne vois quand même pas les statuts cachés au demandeur

Added by Benjamin Dauvergne 5 months ago. Updated 3 months ago.

Status:
Solution déployée
Priority:
Normal
Start date:
09 Jan 2019
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No

Description

C'est pour le CD06, en arrivant dans le statut Anonymisation je voudrais supprimer toutes les pièces jointes exportées de mes copies, mais je ne peux pas voir ce statut car FormData.get_json_export_dict() fait:

 969         wf_status = self.get_visible_status()
 970         if wf_status:
 971             data['workflow']['status'] = {'id': wf_status.id, 'name': wf_status.name}

sans prendre en compte l'utilisateur indiqué dans l'appel.

0001-api-check-status-visibility-with-get_user_from_api_q.patch View (3.64 KB) Benjamin Dauvergne, 09 Jan 2019 01:23 PM

0001-modify-tests.patch View (1.9 KB) Benjamin Dauvergne, 09 Jan 2019 03:41 PM

0002-api-check-status-visibility-with-get_user_from_api_q.patch View (3.64 KB) Benjamin Dauvergne, 09 Jan 2019 03:41 PM

0001-modify-tests.patch View (1.9 KB) Benjamin Dauvergne, 02 Mar 2019 05:12 PM

0002-api-check-status-visibility-with-get_user_from_api_q.patch View (3.61 KB) Benjamin Dauvergne, 02 Mar 2019 05:12 PM

0001-api-check-status-visibility-against-authenticated-AP.patch View (5.4 KB) Benjamin Dauvergne, 04 Mar 2019 09:48 AM


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

Associated revisions

Revision c8023e67 (diff)
Added by Benjamin Dauvergne 3 months ago

api: check status visibility against authenticated API user (#29588)

  • thread user through get_json_export_dict() and get_visible_status()
  • modify test_api_list_formdata to get forms with the just_submitted
    status.

History

#1 Updated by Benjamin Dauvergne 5 months ago

Je pose aussi la remarque que ça ne cache rien de fait parce que le statut et de toute façon récupérable via l'id de statut dans les évolutions et un détour via le schéma du workflow, dans wcs-olap j'ai contourné le problème ainsi :

645             # ignore formdata without status
646             if data.workflow.status:
647                 status_id = data.workflow.status.id
648             elif data.evolution:
649                 for evolution in reversed(data.evolution):
650                     if evolution.status:
651                         status_id = evolution.status
652                         break
653                 else:
654                     continue
655             else:
656                 continue
657 
658             try:
659                 status = data.formdef.schema.workflow.statuses_map[status_id]
660             except KeyError:
661                 self.logger.warning('%s.%s unknown status status_id %s',
662                                     data.formdef.schema.name, data.id, status_id)
663                 continue

#2 Updated by Benjamin Dauvergne 5 months ago

  • Assignee set to Benjamin Dauvergne

#3 Updated by Benjamin Dauvergne 5 months ago

Voilà ça passe tous les tests actuels mais on en manque sur ces aspects donc le reste du taf c'est de faire des tests adaptés.

#4 Updated by Benjamin Dauvergne 5 months ago

  • Status changed from Solution proposée to En cours

#5 Updated by Benjamin Dauvergne 5 months ago

Modification des tests pour bien observer le changement (avant ça foire, après ça passe), à noter que de toute façon l'API de listing est impossible à appeler sans un utilisateur concerné par le workflow (si on voulait avoir un test vérifiant que le statut disparaît bien dans ce cas, il faudrait ouvrir cette possibilité).

#6 Updated by Benjamin Dauvergne 4 months ago

Rebasé, poussé pour tests sur master récent.

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

Réunir les deux, ou mettre un meilleur sujet à 0001. Et je n'aime toujours pas les mentions (fixes #...) qui provoquent parfois des choses inopportunes dans redmine.

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

  • Status changed from Solution proposée to Solution validée

#10 Updated by Benjamin Dauvergne 3 months ago

  • Status changed from Solution validée to Résolu (à déployer)

#11 Updated by Frédéric Péters 3 months ago

  • Status changed from Résolu (à déployer) to Solution déployée

#12 Updated by Benjamin Dauvergne about 2 months ago

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

Also available in: Atom PDF