Bug #14076
attribution de workflow/catégorie après "écraser par nouvel import"
0%
Description
Dans "écraser par un nouvel import" on passe include_id=True, et il y a un attribut workflow_id, et donc on se trouve à chercher le workflow uniquement par son id :
if include_id and workflow_node.attrib.get('workflow_id'): workflow_id = workflow_node.attrib.get('workflow_id') if Workflow.has_key(workflow_id): formdef.workflow_id = workflow_id else: workflow = workflow_node.text.encode(charset) for w in Workflow.select(): if w.name == workflow: formdef.workflow_id = w.id break
Et donc mille chance de ne pas le trouver, le formulaire rebascule sur le workflow par défaut, toutes les demandes partant en sucette.
Files
Associated revisions
History
Updated by Frédéric Péters about 8 years ago
- File 0001-admin-add-screen-when-overwriting-a-formdef-and-work.patch 0001-admin-add-screen-when-overwriting-a-formdef-and-work.patch added
- Status changed from Nouveau to En cours
- Patch proposed changed from No to Yes
Sans doute il faudrait quelques mots sympas pour expliquer pourquoi on demande de valider la sélection de workflow mais je n'avais pas trop d'idées sur quoi y dire.
Updated by Frédéric Péters about 8 years ago
- Subject changed from attribution de workflow après "écraser par nouvel import" to attribution de workflow/catégorie après "écraser par nouvel import"
Le même problème se pose pour la catégorie; l'id prime et le formulaire peut donc se trouver déplacé par mégarde.
Updated by Thomas Noël about 8 years ago
Frédéric Péters a écrit :
Sans doute il faudrait quelques mots sympas pour expliquer pourquoi on demande de valider la sélection de workflow mais je n'avais pas trop d'idées sur quoi y dire.
Il faudrait au moins dire que le choix est super important car il peut modifier les demandes liées. Tiens d'ailleurs, si on change de workflow, a priori on ne va pas passer par la page qui permet de faire les ré-attribution de statut ?
Et aussi, est-ce qu'on pourrait pré-selectionner dans le select le premier workflow qui a un nom égal à different_workflow.name ? Et si on n'en trouve pas, avoir en premier choix un "Choisissez..." qui fasse que si on clique juste sur "Submit", ça ne passe pas.
Updated by Frédéric Péters about 8 years ago
Tiens d'ailleurs, si on change de workflow, a priori on ne va pas passer par la page qui permet de faire les ré-attribution de statut ?
Non; il est d'autant plus important de noter qu'il faut vraiment faire gaffe ici et sélectionner le bon workflow.
Et aussi, est-ce qu'on pourrait pré-selectionner dans le select le premier workflow qui a un nom égal à different_workflow.name ?
Si jamais il y en a qui existe, sinon afficher le workflow actuel comme maintenant.
Updated by Thomas Noël about 8 years ago
Ok.
Pour le message, en français, je dirais un truc avec des mots qui font un peu peur :
« Vérifiez bien le choix du workflow lié à ce formulaire, il doit être identique au workflow utilisé pour la gestion des demandes actuelles. Si ce n'est pas le cas, les demandes en cours risquent de se retrouver dans des statuts inexistants ou incohérents ! » (oui, avec un !)
Updated by Frédéric Péters about 8 years ago
- File 0001-admin-don-t-change-category-workflow-when-overwritin.patch 0001-admin-don-t-change-category-workflow-when-overwritin.patch added
En fait, j'ai l'impression de trop de précipitation vers un truc trop compliqué, je propose du coup de beaucoup plus simplement et sans danger de conserver la catégorie et le workflow courant (comme on le fait pour l'id, l'url name et le nom de la table sql).
Updated by Frédéric Péters about 8 years ago
- Status changed from En cours to Résolu (à déployer)
commit 0e4d3342885abff0e9482340a4447bf463505515 Author: Frédéric Péters <fpeters@entrouvert.com> Date: Fri Nov 25 12:55:37 2016 +0100 admin: don't change category/workflow when overwriting a formdef (#14076)
admin: don't change category/workflow when overwriting a formdef (#14076)