Produits Entr'ouvert » w.c.s.

Pour info quand même, parce que je viens de le découvrir, c'est utilisé à Echirolles avec une action de workflow "Créer un document", pour que le fichier de cette action varie d'un formdef à l'autre.

Et à être là-dessus, j'ai fait le tour des sites en prod (les identifiants sont ceux des formdefs, les valeurs sont les clés contenant quelque chose).

lambersart.au-quotidien.com
   64 ['new*3*subject', 'new*3*to', 'new*3*body']
echirolles.au-quotidien.com
   75 ['2*4*model_file', '4*2*model_file']
   73 ['2*4*model_file', '4*2*model_file']
   74 ['2*4*model_file', '4*2*model_file']
noyelles-godault.au-quotidien.com
   118 ['1*2*amount']
demarches.vincennes.fr
   116 ['2*1*body', '2*1*subject', '5*2*subject', '7*1*subject', '5*1*message', '1*2*url', '13*2*url', '7*1*body', '5*2*body']
   150 ['2*1*body', '2*1*subject', '7*1*subject', '5*1*message', '13*2*url', '1*2*url', '7*1*body']
   123 ['7*1*body', '2*1*body', '1*1*var_intervention_id', '5*2*subject', '5*2*to', '7*1*subject', '2*1*subject', '2*1*to', '5*2*body']
   126 ['7*1*body', '2*1*body', '1*1*var_intervention_id', '5*2*subject', '5*2*to', '7*1*subject', '2*1*subject', '2*1*to', '5*2*body']
   117 ['2*1*body', '2*1*subject', '5*2*subject', '7*1*subject', '5*1*message', '1*2*url', '13*2*url', '7*1*body', '5*2*body']
   124 ['7*1*body', '2*1*body', '1*1*var_intervention_id', '5*2*subject', '5*2*to', '7*1*subject', '2*1*subject', '2*1*to', '5*2*body']
   128 ['5*2*to', '7*1*body', '2*1*body', '1*1*var_intervention_id', '5*2*subject', '7*1*subject', '2*1*subject', '2*1*to', '5*2*body']
   127 ['7*1*body', '2*1*body', '1*1*var_intervention_id', '5*2*subject', '5*2*to', '7*1*subject', '2*1*subject', '2*1*to', '5*2*body']
   148 ['2*1*body', '2*1*subject', '7*1*subject', '5*1*message', '13*2*url', '1*2*url', '7*1*body']
   152 ['2*1*body', '2*1*subject', '7*1*subject', '5*1*message', '1*2*url', '13*2*url', '7*1*body']
   115 ['2*1*body', '2*1*subject', '5*2*subject', '7*1*subject', '5*1*message', '1*2*url', '13*2*url', '7*1*body', '5*2*body']
   151 ['2*1*body', '2*1*subject', '7*1*subject', '5*1*message', '1*2*url', '13*2*url', '7*1*body']
   134 ['2*1*body', '2*1*subject', '5*2*subject', '7*1*subject', '5*1*message', '1*2*url', '13*2*url', '7*1*body', '5*2*body']
   149 ['2*1*body', '2*1*subject', '7*1*subject', '5*1*message', '13*2*url', '1*2*url', '7*1*body']
   118 ['2*1*body', '2*1*subject', '5*2*subject', '7*1*subject', '5*1*message', '1*2*url', '13*2*url', '7*1*body', '5*2*body']
   125 ['5*2*to', '7*1*body', '2*1*body', '1*1*var_intervention_id', '5*2*subject', '7*1*subject', '2*1*subject', '2*1*to', '5*2*body']

Sur « Il faudrait trouver un moyen de pointer précisément le paramétrage qui est "délégué" au formdef. », mon idée :

• Sur la page "options de workflow" du formdef, on affiche tous les statuts et toutes leurs actions du workflow correspondant.
• Pour chaque action, si une valeur est modifiée par le formdef, on l'affiche.
• On cache les autres valeurs — sauf celles à qui il manque une valeur obligatoire, par exemple un appel ws sans URL, une action de saut sans by:
• Sur chaque action :
  • un bouton "voir tous les paramètres de l'action" les affiche, et permet de les surcharger (tous, même ceux qui sont définis dans le workflow).
  • un bouton "remettre les paramètres par défaut"

Note : ça ne fait pas forcément ressortir ce que le développeur du workflow imaginait comme paramètre "configurable". Mais pour ça, je serais plus enclin à ajouter un champ textarea "documentation" sur les workflow où le développeur devrait en expliquer l'utilité, les principes, les options possibles sur un formdef... la doc quoi.

Fin du yaka-fokeu

Je suis d'accord avec Thomas plutôt que de supposer que certains paramétrages sont surchargeables ou pas je les rendrai tous surchargeables. Le travail est plus sur l'interface pour rendre ça digeste comme le suggère Thomas. Sur des cas limites comme cg14 ça sera toujours affreux de toute façon.

Par contre un truc que je ne comprends pas par rapport au commentaire de Thomas: si un champ est obligatoire, il a forcément déjà une valeur dans le workflow et donc comment savoir qu'il faut l'afficher quand même ?

Ma perspective est qu'on n'a pas le même type d'agent pour la création du workflow et pour son utilisation dans un formdef; pour prendre l'exemple Noyelles ici, il y a un champ paramétré, qui est le montant à payer, ça pourrait vraiment se trouver dans une page qui n'a pas vingt champs sans rapports et laissés vides. Et ça baliserait aussi les choses de manière claire et automatique du côté du workflow (et pour un tas de workflows il n'y aurait pas d'options).

Liste des formdefs, puis le nombre de champs des workflow_options complétés, et le nombre de champs total.

lambersart.au-quotidien.com
   64 : 3 / 3
echirolles.au-quotidien.com
   75 : 2 / 2
   73 : 2 / 2
   74 : 2 / 2
noyelles-godault.au-quotidien.com
   118 : 1 / 15
demarches.vincennes.fr
   116 : 9 / 58
   150 : 7 / 58
   123 : 9 / 13
   126 : 9 / 13
   117 : 9 / 58
   124 : 9 / 13
   128 : 9 / 13
   127 : 9 / 13
   148 : 7 / 58
   152 : 7 / 58
   115 : 9 / 58
   151 : 7 / 58
   134 : 9 / 58
   149 : 7 / 58
   118 : 9 / 58
   125 : 9 / 13

Même sur des workflows compliqués Vincennes, avec 58 paramètres exposés, il y en a maximum 9 de pertinents. Je pense vraiment possible pour la personne rédigeant un workflow d'offrir à la personne définissant un formulaire un cadre limité et clair d'options.

Par contre un truc que je ne comprends pas par rapport au commentaire de Thomas: si un champ est obligatoire, il a forcément déjà une valeur dans le workflow et donc comment savoir qu'il faut l'afficher quand même ?

Il n'y a jamais de champ formellement marqué obligatoire dans les actions de workflow, le "obligatoire" de Thomas relève du fonctionnel.

Aussi en rapport avec ce bug j'avais remarqué dans le temps que si on laissait un champ vide dans le workflow, qu'on définissait sa valeur au niveau formulaire puis que finalement on définissait quand même sa valeur dans le workflow, alors la valeur au niveau du formulaire n'était plus éditable mais était toujours prise en compte. C'est peut-être corrigé depuis mais tant qu'à revoir cette partie on pourra vérifier que c'est bien le cas.

C'est toujours comme ça.

(relecture en cours, j'écris des choses au fil de l'eau)

Au niveau des variables de substitution obtenues :

   variables['form_' + field.varname] = ...

... on ne mettrait pas un préfixe plus distinctif, genre form_option_ ? Avec l'idée que si on a un field.varname égale à name, ça écrasera méchamment le form_name.

Dans l'édition d'un champ variable, quand on sélectionne le champ d'une action dans "or you can use this field to directly replace a workflow parameter", il n'est pas pris en compte si le champ précédent "variable name" n'est pas vide.

Je pense que c'est lié au code :

    def _parse(self, request):
        super(WorkflowVariableWidget, self)._parse(request)
        if self.get('name'):
            self.value = self.get('name')
        elif self.get('select'):
            self.value = self.get('select')

et comme on a une un nom de variable fixé par défaut (via un misc.simplify()), j'aurai inversé cette logique : prendre le select en priorité, et s'il n'est pas rempli, prendre le name.

(ou alors en javascript faire un machin qui efface le name quand on sélectionne un select, mais bon, bof bof)

Et, peut-être, en plus, ajouter un "hint" sur le champ select qui dise "Attention, vous devez choisir un nom de variable ou une options dans le workflow, mais les deux sont exclusifs".

Si j'ai bien compris, le "if" dans parameters = [x for x in item.get_parameters() if not getattr(item, x)] fait qu'il est impossible d'avoir une variable qui puisse écraser un paramètre qui serait déjà défini dans le workflow.

Je trouve ça un peu dommage, ça serait bien de pouvoir définir des valeurs dans le workflow, mais d'autoriser leur écrasement via une variable.

Ack ! (en terme de cadre technique ; il restera ensuite des améliorations de présentation, peut-être).