Project

General

Profile

Bug #1241

Gestion de la suppression d'un statut de workflow

Added by Frédéric Péters about 12 years ago. Updated over 10 years ago.

Status:
Fermé
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
27 January 2012
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Planning:

Description

Le patch attaché traite de la gestion des workflows, les différents cas devraient être gérés et dans la situation où un état est supprimé et qu'il y a tentative d'utilisation, une ligne d'erreur est inscrite dans les logs. (un autre patch, ailleurs, pourrait être l'envoi d'un email à l'admin quand une ligne d'erreur est ajoutée).

Ce patch ne corrige rien en ce qui concerne l'affichage, ou le listing de formulaires au statut supprimé. (cf #1171)


Files

wcs.workflow-jumps.diff (12.6 KB) wcs.workflow-jumps.diff Frédéric Péters, 27 January 2012 06:41 PM
delete-reassign-workflows.ptl.diff (3.33 KB) delete-reassign-workflows.ptl.diff Thomas Noël, 31 August 2012 04:41 PM
workflows-modifs.patch (5.44 KB) workflows-modifs.patch Thomas Noël, 03 September 2012 03:35 PM

Related issues

Related to w.c.s. - Bug #1171: Crashes quand une demande est dans un statut qui n'existe plusFermé23 December 2011

Actions

History

#1

Updated by Thomas Noël about 12 years ago

  • Status changed from Solution déployée to En cours

Décision du comité:

Quand un statut va être supprimé, on vérifie s'il y a des demandes dans ce statut :
  • si non : on propose le popup de confirmation simple ;
  • si oui : on affiche un popup qui indique le nombre de demandes dans le statut, et qui demande vers quel autre statut cible les envoyer (et propose également de les supprimer). Le statut ne sera supprimé que si un statut cible est indiqué.
#2

Updated by Thomas Noël about 12 years ago

  • Target version changed from 81 to Au-quotidien 2012.3
#3

Updated by Frédéric Péters over 11 years ago

Le côté suppression d'un statut de workflow, c'est maintenant fait.

commit 9e9308cfd9512576567c145e50403da2b85734b9
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Mon Aug 13 13:43:13 2012 +0200

    admin: do not allow to remove a status in use (#1241)

    Instead, present the user with the possibility to reassign formdata to another
    status, or to remove them.

Il y avait aussi la suppression d'un workflow actuellement utilisé, là plutôt que permettre de réassigner entre workflows, j'ai préféré simplement interdire la suppression.

commit 432f43ae4d4a542f6168570e541cda408bc0ba3f
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Mon Aug 13 14:03:39 2012 +0200

    admin: do not allow removing a workflow that is in use

Reste maintenant comme possibilité d'obtenir des trucs cassés que l'utilisateur change le workflow attaché à un formulaire, je dois encore réfléchir un peu à la manière dont gérer ça (l'interdire ou obliger la suppression des formdata me semble là trop extrème).

#4

Updated by Thomas Noël over 11 years ago

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

Le côté suppression d'un statut de workflow, c'est maintenant fait.

Un truc qui va poser soucis selon moi, c'est qu'on fait juste un "item.status = new_status", sans executer les actions qui correspondent à ce nouveau statut. Ca peut paraître bizarre à l'usage, par exemple si le statut cible contient une action de saut immédiat (jump), le saut ne sera jamais executé.

On pourrait donc juste ajouter une petite phrase "Attention, les actions correspondantes au statut choisi ne seront pas exécutées". Ou proposer de choisir si les actions doivent être exécutées ou pas...

#5

Updated by Frédéric Péters over 11 years ago

Je verrais plutôt s'il y a moyen de ne pas proposer les statuts "techniques", sur lesquels l'utilisateur n'est pas supposé s'arrêter. (je n'ai pas d'idée précise là tout de suite).

#6

Updated by Frédéric Péters over 11 years ago

Voilà, réassignation des statuts quand l'utilisateur demande à modifier le workflow d'un formdef contenant des formdata.

commit d99af3f0751373f9d670c4692fae51ae3d8d934e
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Mon Aug 13 22:46:07 2012 +0200

    admin: reassign formdata status on workflow change

Je réfléchirai demain à la question des statuts "techniques".

#7

Updated by Frédéric Péters over 11 years ago

  • Status changed from En cours to Résolu (à déployer)

Bon, plutôt que réfléchir je vais noter qu'il faudra penser à mentionner dans la documentation qu'il faut bien veiller à ne réaffecter que vers des statuts "possibles".

#8

Updated by Frédéric Péters over 11 years ago

Il a bien fallu réfléchir, parce que c'était utile voire nécessaire aussi ailleurs.

commit b1e529be50b0921a335ba3f33b44611ee98f8ec8
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Fri Aug 17 10:01:51 2012 +0200

    workflows: add and use the possibility to know about "waitpoint" status

    A waitpoint status is a status waiting for an event (be it user
    interaction or something else), but can also be an endpoint (where the
    user would wait, infinitely).

    This is used to avoid "technical status" (that are just there to execute
    some actions and redirect the user elsewhere) in different places, such
    as the status filter for forms (because theorically it's not possible
    to have forms with that status), or when reassigning status on workflow
    changes (to avoid putting the form in a "stuck" situation).
#9

Updated by Thomas Noël over 11 years ago

Avec les actions conditionnées par des tests (y compris les sauts automatiques), ça pourrait être casse-gueule dans des cas limites (par exemple, ne pas afficher des status en pensant qu'ils sont "techniques", alors que non, ou l'inverse).

Mais les gens qui font des workflows complètements tordus feraient mieux de programmer des actions plus adaptées en Python ; donc j'approuve quand même.

Je reste quand même sur l'idée que le jour où il y aura une doc d'utilisation de w.c.s. (sic), il faudra indiquer que les reassign de statuts ne sont pas à l'épreuve des balles.

#10

Updated by Thomas Noël over 11 years ago

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

Voilà, réassignation des statuts quand l'utilisateur demande à modifier le workflow d'un formdef contenant des formdata.
commit d99af3f0751373f9d670c4692fae51ae3d8d934e
Je réfléchirai demain à la question des statuts "techniques".

Je propose ça, pour que les statuts dans les historiques des demandes ne deviennent pas n'importe quoi (i.e. on change tous les codes de tous les status de l'historique... c'est le moindre mal) :

--- a/wcs/admin/forms.ptl
+++ b/wcs/admin/forms.ptl
@@ -576,22 +576,25 @@ class FormDefPage(Directory):

     def workflow_status_remapping_submit(self, form):
         status_mapping = {}
         for status in self.formdef.workflow.possible_status:
             status_mapping['wf-%s' % status.id] = 'wf-%s' % \
                     form.get_widget('mapping-%s' % status.id).parse()
         for item in self.formdef.data_class().select():
             item.status = status_mapping.get(item.status)
+            if not item.evolution:
+                item.evolution = []
+            else:
+                for evo in item.evolution:
+                    evo.status = status_mapping.get(evo.status)
             evo = Evolution()
             evo.time = time.localtime()
             evo.status = item.status
             evo.comment = _('Administrator changed workflow, reassigned status')
-            if not item.evolution:
-                item.evolution = []
             item.evolution.append(evo)
             item.store()
#11

Updated by Frédéric Péters over 11 years ago

Nickel, pousse donc ça.

#12

Updated by Thomas Noël over 11 years ago

Autre soucis du même type, quand on supprime juste un seul statut, que faut-il faire des evolutions ? Est-ce que je les modifie aussi ? (là encore, c'est pas forcément super logique, mais c'est mieux que d'avoir des vieux wf-X qui ne correspondent plus à rien...?)

-> Point à discuter avec Victor

#13

Updated by Thomas Noël over 11 years ago

  • Status changed from Résolu (à déployer) to En cours
#14

Updated by Frédéric Péters over 11 years ago

Je dirais qu'on les met à None, ou une valeur particulière, qu'on traite en l'affichant comme 'Inconnu'.

#15

Updated by Thomas Noël over 11 years ago

Patch proposé : dans le cas de changement de workflow, on réaffecte les statuts des demandes et des historiques... mais on n'ajoute rien dans l'historique. Parce que ça sert pas vraiment et que ça risque juste de rendre le truc pas bien compréhensible pour les demandeurs :

diff --git a/wcs/admin/forms.ptl b/wcs/admin/forms.ptl
index 50be46a..d90b6a8 100644
--- a/wcs/admin/forms.ptl
+++ b/wcs/admin/forms.ptl
@@ -589,16 +589,9 @@ class FormDefPage(Directory):
                     form.get_widget('mapping-%s' % status.id).parse()
         for item in self.formdef.data_class().select():
             item.status = status_mapping.get(item.status)
-            if not item.evolution:
-                item.evolution = []
-            else:
+            if item.evolution:
                 for evo in item.evolution:
                     evo.status = status_mapping.get(evo.status)
-            evo = Evolution()
-            evo.time = time.localtime()
-            evo.status = item.status
-            evo.comment = _('Administrator changed workflow, reassigned status')
-            item.evolution.append(evo)
             item.store()

     def get_preview [html] (self):
#16

Updated by Thomas Noël over 11 years ago

Et un peu dans la même veine, un patch sur la suppression d'un status :
- modifie les historiques pour y remplacer le status supprimé par "Inconnu" (evo.status = None)
- supprimer effectivement le statut après réassignation ou suppression des formulaires

#17

Updated by Thomas Noël over 11 years ago

Un patch qui reprend tout (modif du wf affecté à un form, et suppression d'un status dans un wf), avec un peu de log.

#18

Updated by Victor Claudet over 11 years ago

  • Target version changed from Au-quotidien 2012.3 to Au-quotidien 2014.5
#19

Updated by Frédéric Péters almost 11 years ago

  • Status changed from En cours to Fermé

Il me semble que tout ça a été commité.

#20

Updated by Frédéric Péters over 10 years ago

  • Target version deleted (Au-quotidien 2014.5)

Also available in: Atom PDF