Projet

Général

Profil

Development #47878

distinguer la première demande lors d'une action de masse

Ajouté par Frédéric Péters il y a plus de 3 ans. Mis à jour il y a plus de 3 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
20 octobre 2020
Echéance:
06 novembre 2020
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

Pour le développement d'une action globale type "dédoublonnage", où on voudrait un traitement différent entre la première demande et les autres de la série.

Quelque chose qui a priori se trouverait un peu comme ça :

@@ -1884,11 +1884,19 @@ class FormPage(Directory):
             def execute(self, job=None):
                 formdatas = self.formdef.data_class().get_ids(self.item_ids)
                 job.completion_status = '{}/{}'.format(0, len(formdatas))
                 job.store()
                 publisher = get_publisher()
+                # conserver initial_formdata = formdatas[0]
                 for i, formdata in enumerate(formdatas):
                     publisher.substitutions.reset()
                     publisher.substitutions.feed(publisher)
                     publisher.substitutions.feed(self.formdef)
                     publisher.substitutions.feed(formdata)
+                    # faire un feed(initial_formdata, alternative_prefix='initial_form')
+                    # (à voir exactement la forme à adopter pour avoir comme ça
+                    # un préfixe alternatif)
+                    #  genre autre possibilité
+                    #    ...feed({'initial_form': LazyFormData(initial_formdata)})
+                    #    (ou sinon cf CallerSource dans wcs/wf/external_workflow.py)
+                    # + feed de {
+                    #   mass_action_index: i,
+                    #   mass_action_length: len(formdatas)  # peut-être
+                    #  }
                     if getattr(self.action['action'], 'status_action', False):
                         # manual jump action
                         from wcs.wf.jump import jump_and_perform
@@ -1904,6 +1912,7 @@ class FormPage(Directory):
             item_ids = FormDefUI(self.formdef).get_listing_item_ids(
                         selected_filter, user=get_request().user, query=query,
                         criterias=criterias)
+        # peut-être forcer un tri sur les item_ids pour assurer que tout le temps ça vienne pareil
         action_job = ActionJob(self.formdef, get_request().get_query(), action, item_ids)
         job = get_response().add_after_job(
                 _('Executing task "%s" on forms') % action['action'].name,


Fichiers

Révisions associées

Révision ef032317 (diff)
Ajouté par Frédéric Péters il y a plus de 3 ans

storage: add parameter to sort get_ids results (#47878)

Révision 20159ae3 (diff)
Ajouté par Frédéric Péters il y a plus de 3 ans

misc: keep track of oldest formdata when running a mass action (#47878)

Historique

#1

Mis à jour par Frédéric Péters il y a plus de 3 ans

  • Echéance mis à 06 novembre 2020
#2

Mis à jour par Frédéric Péters il y a plus de 3 ans

#4

Mis à jour par Thomas Noël il y a plus de 3 ans

« formdata IDs so we know for sure the processing order » : mmmh... les "id" ne suivent pas l'ordre chronologique demandé par le "cahier des charges" ; une demande n°4 qui a passé 2 jours en brouillon va être finalement plus récente que la 5.

Si on arrive à avoir le vrai ordre chronologique, plutôt que "first_form" j'aurais pensé à "oldest_form" qui me semble plus clair, ça précise le critère de tri.

En dehors ça, en terme d'utilisation ça me semble assez casse-gueule, l'agent va cliquer sur 3 demandes dans le listing en s'imaginant que c'est la première "tout en haut" qui va être la principale, mais en fait ça sera la plus ancienne... Il va falloir bien bien expliquer ça (et s'en rappeler).

(aussi y'a un vieux commentaire qui traine « # conserver initial_formdata = formdatas0 »)

#5

Mis à jour par Frédéric Péters il y a plus de 3 ans

En dehors ça, en terme d'utilisation ça me semble assez casse-gueule, l'agent va cliquer sur 3 demandes dans le listing en s'imaginant que c'est la première "tout en haut" qui va être la principale (...)

Je pense ça va aller, avec la "bonne" demande en bas de la liste.

Pour le tri par id versus vrai chronologique, oui c'est vrai, je vais reprendre ça différemment.

#7

Mis à jour par Thomas Noël il y a plus de 3 ans

Et pour mon idée de nommer le truc "oldest_form", j'imagine que tu trouves ça tout moche, c'est ça ? :-)

#8

Mis à jour par Frédéric Péters il y a plus de 3 ans

Oui :)

#9

Mis à jour par Thomas Noël il y a plus de 3 ans

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

Bon, allez, je plie.

#10

Mis à jour par Thomas Noël il y a plus de 3 ans

Thomas Noël a écrit :

Bon, allez, je plie.

Et sinon "reference_form" ? Non ? Bon.

#11

Mis à jour par Frédéric Péters il y a plus de 3 ans

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

Changé sur le fil en oldest_.

commit 20159ae39bb9e843867e7799b40c0ebd831b4dc6
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Mon Nov 2 14:55:45 2020 +0100

    misc: keep track of oldest formdata when running a mass action (#47878)

commit ef03231782deda80d2ab1acdb8b32fda4937f445
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Mon Nov 16 19:13:51 2020 +0100

    storage: add parameter to sort get_ids results (#47878)

Notes pour l'utilisation/la documentation :

  • il y a une variable mass_action_index qui contient l'index d'exécution, une condition "mass_action_index != 0" sur l'action globale permettra d'exécuter une action sauf pour la première / plus ancienne demande.
  • lors de l'exécution de l'action, quelle que soit la demande, une variable oldest_form est disponible (ainsi que tout ce qu'il y a dessous, ex: oldest_form_number, oldest_form_var_plop, etc.).
#12

Mis à jour par Frédéric Péters il y a plus de 3 ans

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

Formats disponibles : Atom PDF