Projet

Général

Profil

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

Ajouté par Benjamin Dauvergne il y a plus de 5 ans. Mis à jour il y a environ 5 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
09 janvier 2019
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:

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.


Fichiers


Demandes liées

Lié à OLAP / Business Intelligence pour Publik - Development #32607: utiliser le flag show-hidden-status=trueRejeté24 avril 2019

Actions

Révisions associées

Révision c8023e67 (diff)
Ajouté par Benjamin Dauvergne il y a environ 5 ans

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.

Historique

#1

Mis à jour par Benjamin Dauvergne il y a plus de 5 ans

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

Mis à jour par Benjamin Dauvergne il y a plus de 5 ans

  • Assigné à mis à Benjamin Dauvergne
#3

Mis à jour par Benjamin Dauvergne il y a plus de 5 ans

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

Mis à jour par Benjamin Dauvergne il y a plus de 5 ans

  • Statut changé de Solution proposée à En cours
#5

Mis à jour par Benjamin Dauvergne il y a plus de 5 ans

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

#7

Mis à jour par Frédéric Péters il y a environ 5 ans

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

Mis à jour par Frédéric Péters il y a environ 5 ans

  • Statut changé de Solution proposée à Solution validée
#10

Mis à jour par Benjamin Dauvergne il y a environ 5 ans

  • Statut changé de Solution validée à Résolu (à déployer)
#11

Mis à jour par Frédéric Péters il y a environ 5 ans

  • Statut changé de Résolu (à déployer) à Solution déployée
#12

Mis à jour par Benjamin Dauvergne il y a environ 5 ans

Formats disponibles : Atom PDF