Bug #35768
Saut automatique non exécuté si saisie backoffice
0%
Description
Dans formulaire et workflow ci-joint (versions simplifiées de #35742), si saisie backoffice, on reste sur le statut 'Orientation agenda prise de rdv', alors que ça devrait sauter vers un des trois statuts 'Pose rdv xxx'.
Bizarrement si on supprime dans le formulaires les 3 champs 'Sélectionnez votre créneau de rdv au centre XXX', plus de bug.
Fichiers
Révisions associées
Historique
Mis à jour par Nicolas Roche il y a plus de 4 ans
Formulaire :
- Texte (ligne) - {{form_var_nom}}
- Données de traitement : {{form_var_nom_agenda}}
Les deux identifiants commencent par 'nom'.
Si on change un des deux identifiants pour qu'il ne commence plus par 'nom', alors l'évaluation de la donnée de traitement permet le saut comme attendu.
J'essaye d'écrire un test qui le met en évidence...
Mis à jour par Nicolas Roche il y a plus de 4 ans
il faut réunir 2 conditions pour que ça plante :
- que le prefix du nom de la variable de traitement soit le nom d'une variable du formulaire
- qu'il y ait une condition d'affichage sur un champ du formulaire (cette seconde condition explique la bizarrerie énoncée par Manu dans la description du ticket)
def test_backoffice_conditional_jump_base_on_bo_field(pub): """test name clashs between form variable and backoffice field, when having an unrelated conditional field""" user = create_superuser(pub) Workflow.wipe() workflow = Workflow(name='form-title') workflow.backoffice_fields_formdef = WorkflowBackofficeFieldsFormDef(workflow) workflow.backoffice_fields_formdef.fields = [ fields.StringField( id='0', varname='foo_bovar', type='string', label='bo variable'), ] st1 = workflow.add_status('Status1', 'st1') setbo = SetBackofficeFieldsWorkflowStatusItem() setbo.parent = st1 setbo.fields = [{'field_id': '0', 'value': 'go'}] st1.items.append(setbo) jump = JumpWorkflowStatusItem() jump.status = 'st2' st1.items.append(jump) jump.parent = st1 st2 = workflow.add_status('Status2', 'st2') jump = JumpWorkflowStatusItem() jump.condition = {'type': 'django', 'value': "form_var_foo_bovar == 'go'"} jump.status = 'st3' st2.items.append(jump) jump.parent = st2 st3 = workflow.add_status('Status3', 'st3') workflow.store() # working: # BO field varname prefix (foo) != FO field varname (bar) FormDef.wipe() formdef = FormDef() formdef.name = 'form-title' formdef.fields = [ fields.TextField(id='1', varname='bar', type='text', label='bar variable'), fields.TextField(id='2', varname='var3', type='text', label='n/a', condition={'type': 'django', 'value': 'True'} ), ] formdef.confirmation = False formdef.workflow_id = workflow.id formdef.backoffice_submission_roles = user.roles[:] formdef.store() formdef.data_class().wipe() app = login(get_app(pub)) resp = app.get('/backoffice/submission/form-title/') resp.form['f1'].value = 'foo2' resp.form['f2'].value = 'bar2' resp = resp.form.submit('submit').follow() assert 'New submission' in resp.body resp = app.get('/backoffice/management/form-title/1/', status=200) status = re.findall(r'.*Status: ([^<]*).*', resp.body) assert status[0] == 'Status3' # working: # no condition on an unrelated FO field FormDef.wipe() formdef = FormDef() formdef.name = 'form-title' formdef.fields = [ fields.TextField(id='1', varname='foo', type='text', label='foo variable'), fields.TextField(id='2', varname='var3', type='text', label='n/a', #condition={'type': 'django', 'value': 'True'} ), ] formdef.confirmation = False formdef.workflow_id = workflow.id formdef.backoffice_submission_roles = user.roles[:] formdef.store() formdef.data_class().wipe() app = login(get_app(pub)) resp = app.get('/backoffice/submission/form-title/') resp.form['f1'].value = 'foo3' resp.form['f2'].value = 'bar3' resp = resp.form.submit('submit').follow() assert 'New submission' in resp.body resp = app.get('/backoffice/management/form-title/1/', status=200) status = re.findall(r'.*Status: ([^<]*).*', resp.body) assert status[0] == 'Status3' # not working: # BO field varname prefix (foo) == FO field varname (foo) # and there is a condition on an unrelated FO field FormDef.wipe() formdef = FormDef() formdef.name = 'form-title' formdef.fields = [ fields.TextField(id='1', varname='foo', type='text', label='fo variable'), fields.TextField(id='2', varname='var3', type='text', label='n/a', condition={'type': 'django', 'value': 'True'} ), ] formdef.confirmation = False formdef.workflow_id = workflow.id formdef.backoffice_submission_roles = user.roles[:] formdef.store() formdef.data_class().wipe() app = login(get_app(pub)) resp = app.get('/backoffice/submission/form-title/') resp.form['f1'].value = 'foo' resp.form['f2'].value = 'bar' resp = resp.form.submit('submit').follow() assert 'New submission' in resp.body resp = app.get('/backoffice/management/form-title/1/', status=200) status = re.findall(r'.*Status: ([^<]*).*', resp.body) assert status[0] == 'Status3'
Mis à jour par Frédéric Péters il y a plus de 4 ans
Je veux bien une reformulation en français limitée aux éléments pertinents maintenant que le problème a précisément été trouvé.
Mis à jour par Nicolas Roche il y a plus de 4 ans
- Fichier workflow-test-saisie-backoffice.wcs workflow-test-saisie-backoffice.wcs ajouté
- Fichier form-test-saisie-backoffice.wcs form-test-saisie-backoffice.wcs ajouté
J'ai réduit le formulaire et le workflow de rouen pour isoler le bug (ci-joint).
Et c'est ce couple que j'ai reproduit dans le test ci-dessus.
Le workflow devrait passer de l'état 2 à l'état 3 sur un saut automatique déclenché par une condition sur une variable de traitement (évaluée dans l'état 1). Cela fonctionne comme attendu via la saisie par le portail utilisateur. Par contre ça ne fonctionne pas lorsque l'on utilise la saisie backoffice.
- Pas de chance, la variable de traitement s’appelle 'XXX_YYY' alors qu'une variable du formulaire s’appelle 'XXX'.
- Pas de chance non plus, un autre champ du formulaire a une condition d'affichage (complètement indépendante).
Le cumul de ces 2 conditions en saisie backoffice (merci à Rouen pour être tombé dessus) fait que le saut ne se déclenche pas, bien que la variable de traitement affiche une valeur correcte dans l'inspecteur.
Il y a encore un effet de bord à signaler, pour déboguer j'ai mis en place une action globale 'reset' qui me permettait de revenir au premier statut du workflow. Or quand je l'utilisais le saut vers l'état 3 ne posait plus de problème. Peut-être parce que dans cas je sortais du cadre de la saisie backoffice.
Mis à jour par Frédéric Péters il y a plus de 4 ans
J'insiste un peu, lire cent lignes de tests ou devoir ouvrir/importer des fichiers, c'est pareillement encore pas mal de taf de compréhension qui est demandé à la personne arrivant sur le ticket. J'imaginais quelque chose de plus immédiat, genre quand il y a un champ avec xxx comme identifiant et une donnée de traitement avec xxx_yyy comme identifiant, une condition qui dit "..." dans un saut n'est pas évaluée correctement.
Bien sûr ça peut être plus long, là il semble s'ajouter "quand c'est une saisie en backoffice", peut-être aussi "quand il y a en même temps un champ avec des conditions".
Et peut-être que cette description n'est pas nécessaire, peut-être que juste le test qui reproduit la situation, et uniquement celle-là, remplirait l'objectif de décrire intégralement ce qui ne marche pas.
Mis à jour par Nicolas Roche il y a plus de 4 ans
Désolé, je n'ai pas réussi à extraire l'essentiel dans ma précédente reformulation,
notamment en ajoutant le fomulaire et le workflows qui en fait sont redondant avec le test.
Je reformule :
- en saisie backoffice,
- si la variable de traitement s’appelle 'XXX_YYY' et qu'il existe une variable de formulaire qui s’appelle 'XXX',
- si un autre champ du formulaire a une condition d'affichage.
Mis à jour par Frédéric Péters il y a plus de 4 ans
- Fichier workflow-35800.wcs workflow-35800.wcs ajouté
- Fichier form-35800.wcs form-35800.wcs ajouté
De cette description je crée formulaire et workflow attachés (il faut un rôle "Debug") et je fais une saisie backoffice j'écris "toto" dans form_var_xxx, il y a sur la page un autre champ, conditionnel basé sur form_var_xxx, je valide la page, je valide la page de validation, j'arrive sur la demande, qui est bien passée en "statut2".
Mis à jour par Frédéric Péters il y a plus de 4 ans
ok, me manquait visiblement "condition sur une variable de traitement".
Mis à jour par Frédéric Péters il y a plus de 4 ans
- Fichier 0001-backoffice-clean-context-after-submission-before-wor.patch 0001-backoffice-clean-context-after-submission-before-wor.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
De manière amusante c'est #32558.
Mis à jour par Thomas Noël il y a plus de 4 ans
Ack.
(Je n'ai pas d'idée d'un autre nom pour «clean_submission_context» qui fait penser qu'on parle du mode "submission" (saisie backoffice) alors qu'en fait non, c'est juste le submit générique du formulaire... bref : ack)
Mis à jour par Thomas Noël il y a plus de 4 ans
- Statut changé de Solution proposée à Solution validée
Mis à jour par Frédéric Péters il y a plus de 4 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit a4f2fa11580bb5d4714f3ca1d0c9f290faefc1de Author: Frédéric Péters <fpeters@entrouvert.com> Date: Sat Sep 7 12:14:09 2019 +0200 backoffice: clean context after submission, before workflow (#35768)
Mis à jour par Frédéric Péters il y a plus de 4 ans
- Statut changé de Résolu (à déployer) à Solution déployée
backoffice: clean context after submission, before workflow (#35768)