Produits Entr'ouvert » w.c.s.

Brice Mallet a écrit :

• action interactive (affichage d'un bouton)

En général on ne fait plus d'action qui affiche un boutons, on utilise les sauts par généricité.

Benjamin Dauvergne a écrit :

Brice Mallet a écrit :

• action interactive (affichage d'un bouton)

En général on ne fait plus d'action qui affiche un boutons, on utilise les sauts par généricité.

Oui, ça permettra d'utiliser l'action dans d'autres situations, par exemple de créer plusieurs demandes, etc. L'action "création d'un brouillon" devra créer ce qu'il faut dans les variables pour permettre l'affichage d'un lien vers le brouillon créé, ou la redirection directe de l'usager vers ce brouillon, etc.

choix de la démarche du nouveau brouillon (identique au formulaire initial et liste explicite)

C'est à dire, soit on coche "même formulaire" (permettant de génériciser le workflow), soit on coche

champ par champ, si un champ fait l'objet d'une recopie, ou pas

Plus génériquement, pour un champ du formulaire cible, dire la valeur à lui attribuer, parmi : gabarit / expression Python / recopie du champ ayant le même identifiant.

Note : tout cela rend l'export/import de workflow assez hasardeux, il faudra sans doute rendre l'import intelligent (ne pas se baser que sur les slugs, prendre aussi en charge les noms des formulaires, etc)

Thomas Noël a écrit :

Benjamin Dauvergne a écrit :

Brice Mallet a écrit :

• action interactive (affichage d'un bouton)

En général on ne fait plus d'action qui affiche un boutons, on utilise les sauts par généricité.

Oui, ça permettra d'utiliser l'action dans d'autres situations, par exemple de créer plusieurs demandes, etc. L'action "création d'un brouillon" devra créer ce qu'il faut dans les variables pour permettre l'affichage d'un lien vers le brouillon créé, ou la redirection directe de l'usager vers ce brouillon, etc.

• ça m'irait qu'on ait un evolutionpart spécifique pour ce job, dans le futur ça pourrait permettre des interactions entre formulaires (ça peut nous aider à résoudre le souci de workflow paralèlles, on lance d'autres workflow et après on pourrait attendre qu'ils atteignent un certain statut)
• le nouvel evolutionpart pourra exporter un LazyFormData pointant sur le nouveau formulaire (prendre en compte le cas où le brouillon est supprimé)
• ça pourrait être utile de ne pas se limiter au statut draft mais de pouvoir directement valider le formulaire (en lien avec mon premier point)

choix de la démarche du nouveau brouillon (identique au formulaire initial et liste explicite)

C'est à dire, soit on coche "même formulaire" (permettant de génériciser le workflow), soit on coche

champ par champ, si un champ fait l'objet d'une recopie, ou pas

Plus génériquement, pour un champ du formulaire cible, dire la valeur à lui attribuer, parmi : gabarit / expression Python / recopie du champ ayant le même identifiant.

Oui.

Note : tout cela rend l'export/import de workflow assez hasardeux, il faudra sans doute rendre l'import intelligent (ne pas se baser que sur les slugs, prendre aussi en charge les noms des formulaires, etc)

Oui et prévoir une étape de recollement comme pour les statuts lors de l'import de workflo

"dans le futur ça pourrait permettre des interactions entre formulaires (ça peut nous aider à résoudre le souci de workflow paralèlles, on lance d'autres workflow et après on pourrait attendre qu'ils atteignent un certain statut)

OUAAAH, ce serait bien en effet

• ça pourrait être utile de ne pas se limiter au statut draft mais de pouvoir directement valider le formulaire (en lien avec mon premier point)

oui

Qui c'est qui chiffre tout cela ? ;-)

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

Reste à une personne motivée à répondre à la question de Brice, "Qui c'est qui chiffre tout cela ?", à celle-ci de chiffrer, puis à développer les tickets w.c.s. qui seront associés.

Là ça m'a pris environ 5h entre le train hier et un peu aujourd'hui, je dirai encore 2j pour rentrer dans le code des tests et écrire les tests pour obtenir une couverture équivalente à resubmit. Je veux bien ouvrir le ticket et y accrocher mon code, plusieurs me semblent inutiles.

À noter dans mon code il manque aussi l'option même formulaire (ce n'est pas vraiment évident comparé à resubmit car il faudrait se restreindre aux champs communs entre les formulaires liés à ce workflow, et les repérer par leur varname, ici je les repèrent par leur id, c'est moins pérenne mais ça permet de viser plus de champs, c'est aussi un point discutable).

+    # lick on first available formdata

c'est dégueulasse.

Par ailleurs, tu aurais quelques explications pour guider la relecture, que ça ne prenne pas des semaines ?

Et en attendant, pour revenir sur un détail de forme, "formdata" n'est pas un mot qu'on veut exposer dans l'interface.

+        if 'varname' in parameters:
+            form.add(VarnameWidget, '%svarname' % prefix,
+                     title=_('Identifier'), value=self.varname,
+                     hint=_('This is used to get generated document in expressions.'),
+                     advanced=not(self.varname))

et on ne veut sans doute pas parler de document ici.

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

Et en attendant, pour revenir sur un détail de forme, "formdata" n'est pas un mot qu'on veut exposer dans l'interface.

Ok je remplace par form dans les deux labels.

[...]

et on ne veut sans doute pas parler de document ici.

Ok j'ai remplacé par :

-                     hint=_('This is used to get generated document in expressions.'),
+                     hint=_('This is used to get linked forms in expressions.'),

branche à jour.

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

Par ailleurs, tu aurais quelques explications pour guider la relecture, que ça ne prenne pas des semaines ?

Le code est assez proche de resubmit, les ajouts c'est principalement l'EvolutionPart qui permet de garder une référence vers les nouvelles demandes via la variable proxy linked et les différentes options (keep_user, backoffice_submission, draft) alors que dans resubmit tout est en dur ou presque.

• l'usage en front est testé en mode anonyme, donc resoumission et ajout du tracking code à la session pour permettre à l'utilisateur de naviguer vers la nouvelle demande,
• l'usage en backoffice avec conservation de l'utilisateur d'origine et création d'un draft en soumission backoffice,
• test import/export XML (au passage j'ajoute une méthode StatusItem.__eq__ pour tester qu'on ne perd rien à l'import)
• test sur la page d'administration pour voir si le widget d'édition des mappings fonctionne à minima en conservant les valeurs déjà présentes

• les proxy pour les variables de substitution,
• l'usage sans passer par un draft

Plus généralement je pense qu'attention doit être portée ici par Serghei, parce que l'action de création de fiche ne peut être qu'une évolution de l'action présentée ici.

Deux parties ne sont pas tellement testées:

Elles pourraient l'être ? Notamment il y a juste un {{ linked.url }} alors que LinkedFormdataSubstitutionProxy par sa taille donne l'impression de permettre davantage.

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

Plus généralement je pense qu'attention doit être portée ici par Serghei, parce que l'action de création de fiche ne peut être qu'une évolution de l'action présentée ici.

En remplaçant les référence explicite à FormDef par un self.formdef_class et en cachant certains paramètre ça ne devrait pas trop poser de problème; il faudra aussi rendre customisable le nom de la variable proxy linked.

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

Plus généralement je pense qu'attention doit être portée ici par Serghei, parce que l'action de création de fiche ne peut être qu'une évolution de l'action présentée ici.

Tout à fait. On se disait cela à l'instant ici avec Thomas. L'interface de configuration de l'action meriterait un généricisation.
Je relis plus en détails.

Dans:

    def _fields_to_options(self, formdef):
        return [(None, '---', '')] + [
            (field.varname, field.label, field.varname) for field in formdef.get_all_varname_fields()]

get_all_varname_fields() élimine les champs sans varname, et en plus expose les champs backoffice or tous les champs peuvent ne pas avoir de nom de variable.
Et les champs backoffice ne doivent pas forcément être remplis. Plutôt utiliser formdef.get_widget_fields(), non?

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

Deux parties ne sont pas tellement testées:

Elles pourraient l'être ? Notamment il y a juste un {{ linked.url }} alors que LinkedFormdataSubstitutionProxy par sa taille donne l'impression de permettre davantage.

• objet proxy testé plus complètement
• cas sans draft testé, ça a d'ailleurs levé un bug sur les variables de substitutions qui m'a obligé à entourer ça d'un with get_publisher().substitutions.freeze()
• ajout d'un champ ItemField pour tester la copie des données structurées

Serghei Mihai a écrit :

Dans:

[...]

get_all_varname_fields() élimine les champs sans varname, et en plus expose les champs backoffice or tous les champs peuvent ne pas avoir de nom de variable.

Oui c'est voulu, on en a discuté à l'eocamp on ne peut pas référencer les champs de manière réutilisable sans passer par les varname ça, on a aucune action où on référence des champs de formulaire autrement que par leur varname.

Et les champs backoffice ne doivent pas forcément être remplis.

Je n'ai pas compris, sur une soumission direct on pourra remplir les champs BO sur un draft non (il n'y a pas de contrôle contre ça mais je sais que ça ne marchera pas). Il n'y aucune obligation de les remplir.

Voilà, couverture à 91 %. Il reste une méthode repr, des except ou des cas limites.

https://jenkins.entrouvert.org/job/wcs-wip/job/wip%252F33186-Initialisation-d-un-brouillon/13/Coverage_20Report_20_28native_29/

• abstraction de FormDef et LinkedFormdataEvolutionPart
• utilisation de field.id pour les champs cibles au lieu de field.varname et uniquement les champs du formulaire, les champs BO sont désormais exclus

PS: j'ai poussé une branche consolidée au cas où http://git.entrouvert.org/wcs.git/log/?h=wip/33186-Initialisation-d-un-brouillon-consolide

Sur la forme toujours, parce que ça va continuer à inutilement m'ennuyer, je préférerais qu'on n'utilise pas de double préfixe __, que ça reste réservé à Python. (de manière "amusante" il y a une seule occurence aujourd'hui, c'est __key_prefix, parce que code copié/collé/adapté depuis hobo).

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

Sur la forme toujours, parce que ça va continuer à inutilement m'ennuyer, je préférerais qu'on n'utilise pas de double préfixe __, que ça reste réservé à Python. (de manière "amusante" il y a une seule occurence aujourd'hui, c'est __key_prefix, parce que code copié/collé/adapté depuis hobo).

Ok, branche(s) à jour.

(je continue à faire des petites remarques mais j'aimerais une vraie relecture par quelqu'un d'autre)

_~~

Ce "linked" continue à m'ennuyer, il est désormais testé dans davantage de recoins mais à quoi donc va servir tout ça ?

Aussi, plutôt qu'entrer ainsi avec une variable à la racine, je trouve que ça aurait davantage sa place accédé depuis la demande, genre form_links_<created>_url (<created> étant ici l'identifiant donné à l'action).

(pareillement les fichiers attachés auraient plutôt leur place en form_attachments_... et sont à la racine par incident historique).

--- a/wcs/qommon/storage.py
+++ b/wcs/qommon/storage.py
@@ -122,6 +122,10 @@ def deep_bytes2str(obj, seen=None):
...

Ça ne sert plus à rien de toucher à ça, on est en python 3.

À ce sujet sans doute des trucs à retirer aussi côté force_text, force_str.

_~~

evolutionpart_class → evolution_part_class; et je comprends que ces indirections viennent peut-être après mes commentaires à Serghei sur faire la relecture en pensant aux fiches mais autrement j'aurais juste dit d'éliminer cettte indirection.

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

Ce "linked" continue à m'ennuyer, il est désormais testé dans davantage de recoins mais à quoi donc va servir tout ça ?

L'idée c'est de pouvoir suivre les demandes créées depuis la demande d'origine: le cas d'usage le plus ancien que je connais c'est le fait de demander plusieurs validations pour une même demande, mais ça pourrait être aussi quand un truc est géré par deux services : un service accueil et un service technique avec des demandes de formes différentes, le service technique n'ayant pas forcément à connaître le nom du demandeur ou demandant plus de détails ou de mieux structurer une demande générique. Le même EvolutionPart pourrait servir à lier des demandes entre elles aussi (pour éviter les bidouilles +1), ça mais ça demanderait une action particulière.

Aussi, plutôt qu'entrer ainsi avec une variable à la racine, je trouve que ça aurait davantage sa place accédé depuis la demande, genre form_links_<created>_url (<created> étant ici l'identifiant donné à l'action).

Ok, faut que je vois comment faire ça, mais j'ai l'impression qu'avec le mode lazy en fait item.get_substitution_variables() ne sert plus à rien si tout passe par LazyFormData. Si je comprends bien on ne doit plus jamais créer de variable du style form_x_y_z on doit tout poser dans LazyFormData et c'est CompatibilityNamesDict qui s'occupera des deux syntaxes ?

(pareillement les fichiers attachés auraient plutôt leur place en form_attachments_... et sont à la racine par incident historique).

Ok donc on devrait déprécier WorkflowStatusItem.get_substitution_variables() à terme.

Ça ne sert plus à rien de toucher à ça, on est en python 3.

Les tests ne passaient pas sans ça, mais le code a pu changer depuis.

À ce sujet sans doute des trucs à retirer aussi côté force_text, force_str.

Ok.

evolutionpart_class → evolution_part_class; et je comprends que ces indirections viennent peut-être après mes commentaires à Serghei sur faire la relecture en pensant aux fiches mais autrement j'aurais juste dit d'éliminer cettte indirection.

Ok.

L'idée c'est de pouvoir suivre les demandes créées (...)

je comprends ça mais il y a différentes variations dans les appels, qui n'ont peut-être pas toutes une utilité, au moins dans des formes condensées,

• linked|length, nombre de fois où il y a eu une demande créée à partir de celle-ci, utile ?
• linked.status, statut de la demande liée, sans se soucier de l'identifiant de l'action
• linked.resubmited.status, la même chose, pour l'action qui a "resubmited" comme identifiant
• linked.resubmited.0.status, la même chose mais si jamais il y avait plusieurs demandes créées à partir de l'action, prendre la première
• linked.1.status, la même chose que linked.status mais en prenant la deuxième demande créée
• linked.var.foo_string, un champ de la première demande liée.

On pourrait j'espère simplifier, en partant par exemple form_links_, avoir form_links_resubmitted (identifiant de l'action obligatoire), et derrière l'objet lié, et donc comme documentation on noterait que si tu veux form_var_string de la demande liée tu fais form_links_resubmitted.form_var_links.

Et je laisserais à plus tard la réflexion pour accommoder la situation avec plusieurs demandes créées depuis la même action. (dans l'immédiat ma position serait de continuer sur la lancée de simili-queryset de LazyFormDefObjectsManager, et avoir form_links_resubmitted_set, et donc form_links_resubmitted_set.pending pour toutes les demandes créées par l'action et encore en attente, etc.).

_~~

avec le mode lazy (...) CompatibilityNamesDict

L'idée est bien d'arriver à l'utiliser de manière systématique, avec CompatibilityNamesDict pour gérer la syntaxe en underscores.

_~~

Les tests ne passaient pas sans ça, mais le code a pu changer depuis.

Normalement on ne devrait passer dans deep_bytes2str que les objets pickle anciens, et comme tout ça sera fait avant que cette action ne soit employée, jamais rencontrer ici de tuple ou namedtuple.

Les methodes get_varname_fields, get_all_widget_fields, get_all_varname_fields ne servent pas (ou plus), autant ne pas les déclarer.

Benjamin Dauvergne a écrit :

Ok donc on devrait déprécier WorkflowStatusItem.get_substitution_variables() à terme.

Ça ne sert plus à rien de toucher à ça, on est en python 3.

Les tests ne passaient pas sans ça, mais le code a pu changer depuis.

Bon finalement ça servait à quelque chose :

[2020-01-28 16:03:15] exception caught
Exception:
  type = '<class 'AttributeError'>', value = ''Mapping' object has no attribute '__dict__''

Stack trace (most recent call first):
  File "/var/lib/jenkins/workspace/86-Initialisation-d-un-brouillon/wcs/qommon/storage.py", line 134, in deep_bytes2str
   132     seen[id(obj)] = True
   133     if hasattr(obj, '__class__') and obj.__class__.__module__.startswith(('wcs.', 'qommon.', 'modules.')):
>  134         obj.__dict__ = deep_bytes2str(obj.__dict__, seen)
   135         return obj
   136     return obj

Je vais rajouter un not isinstance(obj, tuple) et un commentaire.

Faudrait idéalement voir pourquoi ça arrive là-dedans, parce que normalement ça ne devrait pas. (mais sinon, oui passons et je chercherai moi-même plus tard).

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

L'idée c'est de pouvoir suivre les demandes créées (...)

je comprends ça mais il y a différentes variations dans les appels, qui n'ont peut-être pas toutes une utilité, au moins dans des formes condensées,

• linked|length, nombre de fois où il y a eu une demande créée à partir de celle-ci, utile ?
• linked.status, statut de la demande liée, sans se soucier de l'identifiant de l'action
• linked.resubmited.status, la même chose, pour l'action qui a "resubmited" comme identifiant
• linked.resubmited.0.status, la même chose mais si jamais il y avait plusieurs demandes créées à partir de l'action, prendre la première
• linked.1.status, la même chose que linked.status mais en prenant la deuxième demande créée
• linked.var.foo_string, un champ de la première demande liée.

On pourrait j'espère simplifier, en partant par exemple form_links_, avoir form_links_resubmitted (identifiant de l'action obligatoire), et derrière l'objet lié, et donc comme documentation on noterait que si tu veux form_var_string de la demande liée tu fais form_links_resubmitted.form_var_links.

Et je laisserais à plus tard la réflexion pour accommoder la situation avec plusieurs demandes créées depuis la même action. (dans l'immédiat ma position serait de continuer sur la lancée de simili-queryset de LazyFormDefObjectsManager, et avoir form_links_resubmitted_set, et donc form_links_resubmitted_set.pending pour toutes les demandes créées par l'action et encore en attente, etc.).

Ok je comprends mieux le souci d'uniformité, mais form_links_resubmitted.form_var_links je ne vois pas trop comment le gérer avec les outils actuels ou alors il faut enchaîner les CompatibilityNamesDict pour perpétuer la vieille syntaxe sur des fonctionnalités nouvelles, je ne sais pas si c'est ce qu'on veut plutôt que form_links_resubmitted.var.links.

• rendre varname obligatoire sur cette action
• faire que form.links (sur LazyFormData) propose un dico vers ces varname et rien d'autre
• faire que form.links.resubmitted.form@ renvoie un LazyFormData sur la première demande créée

Ça supportera la syntaxe form_links_resubmitted_form et form_links_resubmitted_form_var_zob mais pas form_links_resubmitted.form_var_zob.

Les tests ne passaient pas sans ça, mais le code a pu changer depuis.

Normalement on ne devrait passer dans deep_bytes2str que les objets pickle anciens, et comme tout ça sera fait avant que cette action ne soit employée, jamais rencontrer ici de tuple ou namedtuple.

Sauf que comme remonté deep_byte2str est appelé systématiquement et pas seulement au moment d'une migration, donc il doit marcher même sur les nouveaux objets ce qui n'est pas le cas ici (un namedtuple est un objet dont la classe est dans w.c.s. mais n'a pas de dict (d'ailleurs je vais juste faire hasattr(obj, '__dict__')).

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

Faudrait idéalement voir pourquoi ça arrive là-dedans, parce que normalement ça ne devrait pas. (mais sinon, oui passons et je chercherai moi-même plus tard).

Ça vient de là :

  File "/var/lib/jenkins/workspace/86-Initialisation-d-un-brouillon/wcs/workflows.py", line 477, in __setstate__
   475     def __setstate__(self, dict):
   476         self.__dict__.update(dict)
>  477         pickle_2to3_conversion(self)
   478         for s in self.possible_status + (self.global_actions or []):
   479             s.parent = self

Ça supportera la syntaxe form_links_resubmitted_form et form_links_resubmitted_form_var_zob mais pas form_links_resubmitted.form_var_zob.

oui, j'ai utilisé le point pour bien marquer la frontière entre les deux mais c'était accessoire.

Ça vient de là :

ok ça doit s'éviter via

     def __setstate__(self, dict):
         self.__dict__.update(dict)
-        pickle_2to3_conversion(self)
+        if six.PY3 and any((isinstance(k, bytes) for k in o.__dict__)):
+            pickle_2to3_conversion(self)
         for s in self.possible_status + (self.global_actions or []):

je regarderai ça.

Un souci que mon implémentation actuelle corrigeait : form_url ne fonctionne pas pour un draft, il y un slash en trop, je vais devoir corriger dans wcs/formdata.py pour que ça passe.

Un souci que mon implémentation actuelle corrigeait : form_url ne fonctionne pas pour un draft, il y un slash en trop, je vais devoir corriger dans wcs/formdata.py pour que ça passe.

C'est visiblement un autre ticket.

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

Un souci que mon implémentation actuelle corrigeait : form_url ne fonctionne pas pour un draft, il y un slash en trop, je vais devoir corriger dans wcs/formdata.py pour que ça passe.

C'est visiblement un autre ticket.

Ouaip, j'ai ouvert #39356 mais j'espère le passer avant pour pouvoir garder mes tests comme ils sont.

Branches à jour, ça inclut la modification proposée pour #39356 (je rebaserai sur la bonne quand ça arrivera) ; aussi la correction à Workflow.__setstate__ au lieu de deep_bytes2str. Toutes les autres modifications demandées sont intégrées (form_links/get_*_fiels inutiles retirés).

Via la modification temporaire de #39356 on peut utiliser simplement form_links.<varname>.form_(backoffice_)url@ et on arrive bien soit sur le draft FO ou le draft BO.

Maintenant il faudrait une relecture complète.

Relu la branche consolidée. Testé en backoffice et it works.

Petite coquille dans le commentaire:

# so we revert to quixote behabiour for adding a line

behabiour => behaviour

Donc go pour moi, mais je laisse aussi Frédéric donner son avis.

J'ai ajouté un ticket nécessaire avant.

Et j'ai beau avoir proposé vite fait cette partie :

-        pickle_2to3_conversion(self)
+        if six.PY3 and any((isinstance(k, bytes) for k in self.__dict__)):
+            pickle_2to3_conversion(self)

je n'en suis pas sûr et crains un existant où l'appel systématique était nécessaire. (et comme mon installation locale est migrée c'est compliqué de faire réapparaitre des années d'existant).

Ma solution préférée, réconfortante, serait bien sûr que ce patch n'introduise pas d'utilisation de tuple/namedtuple, là où tout w.c.s. vivait bien avec liste et dictionnaire.

_~~

(ce conservatisme dans le code étant ma position générale, et qui explique parfois la difficulté de ces relectures, où je dois laisser de côté ce truc où une fixture contient une classe Fixture, ces advanced= sont fait sans parenthèses ou bool() explicites, etc.).

_~~

Il reste aussi des bouts dont je n'ai pas encore compris l'existance, comme le __eq__ tapé sur WorkflowStatusItem.

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

Ma solution préférée, réconfortante, serait bien sûr que ce patch n'introduise pas d'utilisation de tuple/namedtuple, là où tout w.c.s. vivait bien avec liste et dictionnaire.

Ok.

(ce conservatisme dans le code étant ma position générale, et qui explique parfois la difficulté de ces relectures, où je dois laisser de côté ce truc où une fixture contient une classe Fixture, ces advanced= sont fait sans parenthèses ou bool() explicites, etc.).

Ok je réécris tout ça.

_~~

Il reste aussi des bouts dont je n'ai pas encore compris l'existance, comme le __eq__ tapé sur WorkflowStatusItem.

C'est pour le test d'import/export pour l'instant les tests vérifient juste que la sérialisation initiale est égale à elle même dans un cycle sérialisation/désérialisation/sérialisation. Je suis plus rassuré si on y rajoute un test d'égalité par rapport à l'objet de départ. Mais je peux virer ça, d'ailleurs en faisant de Mapping un object ça ne va plus marcher si bien.

Voilà c'est modifié.

• Mapping est une classe classique
• bool(self.varname) pour advanced=
• parenthèses autour des expressions complexes advanced=
• WorkflowStatusItem.__eq__ retiré
• plus de class Fixture

Possibilité de pousser une branche rebasée au-dessus de #39356 ?

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

Possibilité de pousser une branche rebasée au-dessus de #39356 ?

Ok.

Benjamin Dauvergne a écrit :

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

Possibilité de pousser une branche rebasée au-dessus de #39356 ?

Ok.

Voilà c'est rebasé sur master, j'ai lancé uniquement les tests -k create_formdata et corrigé ce qu'il y avait à corriger; il faut attendre l'exécution de jenkins pour voir si autre chose a pu bouger.

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

Je commence (enfin) à utiliser la branche, je clique sur "valider" mais ça me dit erreur, parce que l'identifiant est obligatoire, devrait être sorti des paramètres avancés.

Ok j'ai rendu varname et mappings non requis.

On peut avoir des champs avec des libellés très longs (je pense par exemple aux cases à cocher "J'accepte ceci et cela", ça casse le layout. (cf capture)

Est-ce que je tronque ? Il y a un usage commun ?

J'essaie alors de choisir un autre formulaire mais le champ "Mappings to new form fields", qui est donc vide, m'affiche "champ obligatoire". (je dirais que ça peut rejoindre le point sur la première validation, quand "mappings to new form fields" est vide, valider mais rediriger vers la page d'édition).

Je ne vois pas comment faire cela, sans toucher à tout.

# wcs/admin/workflow. 
        if not form.get_submit() == 'submit' or form.has_errors():
            self.html_top('%s - %s' % (_('Workflow'), self.workflow.name))
            r = TemplateIO(html=True)
            r += htmltext('<h2>%s</h2>') % _(self.item.description)
            r += form.render()
            if self.item.support_substitution_variables:
                r += htmltext('<h3>%s</h3>') % _('Variables')
                r += get_publisher().substitutions.get_substitution_html_table()
            return r.getvalue()
        else:
            self.item.submit_admin_form(form)
            self.workflow.store()
            return redirect('..')

Je peux modifier cela pour faire retourner une valeur à submit_admin_form ?

Pas très clair à quoi sert le libellé de l'action.

Toutes les actions ou presque ont un libellé mais je peux l'enlever.

J'ai testé la création d'un brouillon, je l'ai supprimé, j'ai rejoué l'action, je n'ai pas pu via {{form_links_xxx_form_url}} accéder au nouveau brouillon; vaguement je me dis que ça devrait marcher avec :

[...]

Ok, branche à jour.

Je ne vois pas comment faire cela, sans toucher à tout.

Oui ou avec un truc moche sur un champ cache mis en erreur, laissons ça de côté.

Toutes les actions ou presque ont un libellé mais je peux l'enlever.

Je ne mettrais pas de libellé qui ne sert pas. (dans l'action resubmit le libellé correspondait à un bouton affiché).

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

Je ne vois pas comment faire cela, sans toucher à tout.

Oui ou avec un truc moche sur un champ cache mis en erreur, laissons ça de côté.

Je trouve le comportement actuel désagréable sur toutes les actions, mais oui ce serait bien qu'on puisse éditer sans revenir à chaque fois à la liste des actions (avec un bouton "Enregistrer et continuer les modifications" comme dans l'admin Django) c'est très frustrant comme comportement.

Je ne mettrais pas de libellé qui ne sert pas. (dans l'action resubmit le libellé correspondait à un bouton affiché).

Le label sert aussi, il me semble, à documenter le workflow (via get_line_details()) mais soit, j'ai retiré.

J'ai aussi réordonné les champs pour mettre mappings en second, ça me semble le plus important après le nom du formulaire cible.

Je trouve le comportement actuel désagréable sur toutes les actions (...)

https://dev.entrouvert.org/projects/wcs/issues/new

On peut avoir des champs avec des libellés très longs (je pense par exemple aux cases à cocher "J'accepte ceci et cela", ça casse le layout. (cf capture)

Est-ce que je tronque ? Il y a un usage commun ?

Il y a clairement quelque chose à faire; à regarder alentours il y a la boite de sélection des critères qui fait ellipsize(70) mais ce n'est pas sur un <select>, ici je dirais qu'il y a juste à limiter la largeur du <select>; il serait peut-être bon que tu consultes Thomas sur ce point; de manière imparfaite,

+++ b/wcs/qommon/static/css/dc2/admin.css
...
+.MappingsWidget td:first-child select {
+       max-width: 300px;
+}

branche à jour.

Je n'ai pas regardé ce que ça donne dans la vue inspect, il faudra que je jette un coup d'oeuil à ça.

Dans la vue inspect il n'y aura rien, si on y veut quelque chose, genre une ou deux formes minimales, ça doit aller dans get_static_substitution_variables; a priori profiter de la boucle

        # Add variables from evolution parts classes
        evolution_parts_classes = set(part.__class__ for evolution in self.evolution or [] for part in
                                      evolution.parts or [])
        for klass in evolution_parts_classes:
            if hasattr(klass, 'get_substitution_variables'):
                d.update(klass.get_substitution_variables(self))

et ajouter un get_substitution_variables().

Le travail d'adaptation de la vue inspect au mode "lazy" sort du cadre du ticket.

_~~

Par contre sur le rendu, je pense toujours opportun de demander à Thomas J.

MappingsWidget utilise un table layout (WidgetListAsTable), il existe des alternatives ou je dois proposer une solution avec le table layout ?

Avec ta proposition le "select" prend la moitié de l'écran même si le libellé du champ est court.

Ça n'est pas un problème. (même si perso je serais plutôt pour 30%).

• l'action peut s'appliquer sur les formulaires désactivés, pas nécessaire je pense
• Le comportement par défaut est de créer un brouillon, il m'a fallu un moment pour comprendre pourquoi la demande était pas créée, je souhaiterais qu'on change ça. Ou qu'on change l'intitulé de l'action.
• Aucune info n'est affichée. Je serais d'avis qu'il faut, comme pour l'action création de document, pouvoir enregistrer un truc dans l'historique (comprenant l'URL de la nouvelle demande) si on le souhaite.

#39637, #39638, #39639

Si l'on souhaite créer une demande sur le même formulaire, on devrait pouvoir le faire sans avoir à définir tous les champs un par un comme sur l'ancienne action re-soumission (sauf si un truc m'a échappé)

Il faut ouvrir d'autres tickets, celui-ci est terminé.