Produits Entr'ouvert » w.c.s.

Sûrement cela est-il couvert mais il faut que l'action de création de la fiche puisse prendre en paramètre un uuid d'utilisateur pour l'associer à la fiche (form_user), comme on le fait en créant une fiche en backoffice avec :

{{ eservices_url }}backoffice/data/{{fiche_slug}}/add/?NameID={{uuid}}

L'action ici sera exactement l'action de création d'une nouvelle demande, avec case à cocher "reprendre l'usager", des évolutions seront possibles, après.

Tout à fait.
Je mets à jour la branche sous peu.

+ ok_in_global_action = False

Pourquoi pas ok ?

+ category = 'formdata-action'
+ endpoint = False
+ waitpoint = False
...
+ keep_user = True

Plutôt ne pas redéfinir, à l'identique, ce qui est dans la classe parente, avoir uniquement les différences.

+ form_property_name = 'cards'
...
+ form_property_name = 'links'

Pourquoi les faire apparaitre sous un autre nom, ça reste pour moi des données liées.

+ formdef_label = _('Form')

Et partout ailleurs où _() est utilisé : dans w.c.s. le _ n'est pas lazy, ne peut donc pas être employé là.

+ Mapping(field_id='2', expression='=form_var_list_raw'),
+ Mapping(field_id='3', expression='=form_var_date'),

Dans les tests (comme ailleurs) j'aimerais éviter le recours aux expressions Python; il y a moyen de changer ça en gabarits ? (oui j'ai laissé passer ça dans #33186, pas une raison).

- title=_('Form'),
+ title=self.formdef_label,

Sans appel à gettext ça ne sera pas traduit.

Sans appel à gettext ça ne sera pas traduit.

C'est toujours le cas. Et pour éviter de passer à côté, c'est pareil pour mappings_label et varname_hint.

Aussi, côté libellés,

"Mappings to card fields" vs "Mappings to new form fields" et "Used to get linked card in expressions." This is used to get linked forms in expressions."

Pas de raison pour moi d'avoir ces différences.

Tu peux rebaser ta branche ?

(pour le rebase c'est juste par rapport à un test, ça va se faire sans problème)

Aussi, je pense que l'intention au départ était de mettre toutes les actions sur les fiches dans ce wcs/wf/cards.py mais j'ai l'impression qu'on ne va pas aller vers ça, je serais du coup pour renommer le fichier.

LazyFormDataLinks est importé et pas utilisé.

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

Aussi, je pense que l'intention au départ était de mettre toutes les actions sur les fiches dans ce wcs/wf/cards.py mais j'ai l'impression qu'on ne va pas aller vers ça, je serais du coup pour renommer le fichier.

Ou rajouter le code dans create_formdata.py vu que c'est presque la même action?

Sauf que ça ne correspond pas à "formdata" et comme l'action définit des classes qui se trouvent désormais dans des pickles, référençant le nom du module, celui-ci est désormais figé.

         for part in self._formdata.iter_evolution_parts():
-            if not isinstance(part, LinkedFormdataEvolutionPart):
-                continue
             if part.varname == varname and part.formdata:

Plutôt comparer avec cls que risquer de partir sur un élément d'évolution qui n'aurait aucun rapport.

Je pense plutôt vérifier la présence de l'attribut formdef pour vérifier si l'évolution est bien de type LinkedFormdataEvolutionPart:

Non, vérifier la classe, pas partir sur l'idée qu'un autre objet ne pourra jamais avoir d'attribut formdef.

Aussi, depuis #40359, il faudrait importer N_.