Projet

Général

Profil

Bug #35768

Saut automatique non exécuté si saisie backoffice

Ajouté par Emmanuel Cazenave il y a plus de 4 ans. Mis à jour il y a plus de 4 ans.

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

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

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

workflow-dcjva_cpj_rdv.wcs (5,06 ko) workflow-dcjva_cpj_rdv.wcs Emmanuel Cazenave, 03 septembre 2019 11:49
form-rdv-cpj.wcs (6,18 ko) form-rdv-cpj.wcs Emmanuel Cazenave, 03 septembre 2019 11:49
workflow-test-saisie-backoffice.wcs (1,76 ko) workflow-test-saisie-backoffice.wcs Nicolas Roche, 03 septembre 2019 19:43
form-test-saisie-backoffice.wcs (1,51 ko) form-test-saisie-backoffice.wcs Nicolas Roche, 03 septembre 2019 19:43
workflow-35800.wcs (1,21 ko) workflow-35800.wcs Frédéric Péters, 04 septembre 2019 09:56
form-35800.wcs (1,57 ko) form-35800.wcs Frédéric Péters, 04 septembre 2019 09:56
0001-backoffice-clean-context-after-submission-before-wor.patch (5,92 ko) 0001-backoffice-clean-context-after-submission-before-wor.patch Frédéric Péters, 07 septembre 2019 12:40

Révisions associées

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

backoffice: clean context after submission, before workflow (#35768)

Historique

#2

Mis à jour par Nicolas Roche il y a plus de 4 ans

Je tiens quelque-chose :
Formulaire :
  • Texte (ligne) - {{form_var_nom}}
Workflow :
  • 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...

#3

Mis à jour par Nicolas Roche il y a plus de 4 ans

Voilà,
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'
#4

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

#5

Mis à jour par Nicolas Roche il y a plus de 4 ans

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.

#6

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.

#7

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 :

Un saut automatique déclenché par une condition sur une variable de traitement ne se déclenche pas,
  • 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.
#8

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

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".

#9

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".

#10

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

  • Assigné à mis à Frédéric Péters
#11

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

De manière amusante c'est #32558.

#12

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)

#13

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

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

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)
#15

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

Formats disponibles : Atom PDF