Produits Entr'ouvert » w.c.s.

Je parlais des déclencheurs automatiques, on peut utiliser une expression python comme date de départ, pas une expression Django ou un Gabarit (mais bon j'ai abandonné l'idée d'en faire un ticket parce que je suis pas certain que ça ait bcp d'intérêt).

• Expression (ça prend du Python ou du Django)
• Gabarit

Il y a un « |date:"Y-m-d" » qui sera obligatoire et je trouve ça pas évident du tout à expliquer. Je me pose aussi des questions sur les perfs, quand même.

Il y a un « |date:"Y-m-d" » qui sera obligatoire.

Peut-être pas, ça passe dans get_as_datetime derrière, qui prend y-m-d, d/m/y, et avec les heures aussi. (mais oui si jamais "5 septembre 2019 16:58" ça va pas le faire, et c'est le rendu d'un {{form_receipt_datetime}}).

Je me pose aussi des questions sur les perfs, quand même.

Pas pires que le eval() du Python. (voire bien meilleures si les variables sont statiques en python et lazy en django).

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

Il y a un « |date:"Y-m-d" » qui sera obligatoire.

Peut-être pas, ça passe dans get_as_datetime derrière, qui prend y-m-d, d/m/y, et avec les heures aussi. (mais oui si jamais "5 septembre 2019 16:58" ça va pas le faire, et c'est le rendu d'un {{form_receipt_datetime}}).

Oui sur les dates en général ça va être "5 septembre 2019 16:58". J'en viendrais presque à me demander si on ne pourrait pas changer le format d'affichage des dates par défaut lors du calcul de ces gabarits "techniques" ? En tout cas, je pense qu'on devrait mettre un help_text ici, qui explique qu'il faut une date au format Y-m-d.

Je me pose aussi des questions sur les perfs, quand même.

Pas pires que le eval() du Python. (voire bien meilleures si les variables sont statiques en python et lazy en django).

Oui mon idée derrière ça était de vraiment décourager ces usages (par ailleurs souvent difficiles à comprendre/relire/maintenir), mais je n'ose pas le dire trop fort.

Comme ça revient sur le tapis, je précise que ma seule remarque sur le patch reste qu'il faudrait ajouter un hint qui précise qu'il faut que le gabarit renvoie le format « yyyy-mm-dd H:M » en heure locale (oui, ça peut être d'autres formats, mais celui-là tout le monde va le comprendre).

J'écrivais "mais oui si jamais "5 septembre 2019 16:58" ça va pas le faire, et c'est le rendu d'un {{form_receipt_datetime}})." et ce n'est pas correct, ou plus correct.

{{form_receipt_datetime}} → 17/09/2019 08:05.

Et du coup je ne changerais rien à ma proposition de patch; c'est quand même bien pratique pour l'usager de juste pouvoir taper form_receipt_datetime, ou form_receipt_date, sans avoir à y ajouter un |date:"Y-m-d".

(patch rebasé et poussé dans une branche)

J'ai peut-être rêvé que ça donnait "5 septembre 2019", toutes mes excuses.

Ack sur le principe donc.

Mais...

Poser ce nouveau choix anchor_template au dessus de anchor_expression ?

Il y aussi le hint sur anchor_expression qu'il faudrait reprendre : hint=_('This will only apply to open forms.'),

Et ça peut faire un autre ticket, mais je profiterai bien de l'occasion pour rappeler que ça doit être une date, ça peut paraître évident mais j'ai déjà eu pas mal de questions genre "est-ce que je dois mettre une condition" pour le choix "Expression Python".

• title=_('Expression'), → "Date de référence sous forme d'une expression en Python"
• title=('Text / Template') → "Date de référence sous forme de texte ou de gabarit"

(et si tu ne préfères pas, alors au moins utiliser "String / Template" comme dans le prefill)

J'ai peut-être rêvé que ça donnait "5 septembre 2019", toutes mes excuses.

C'est moi qui l'ai écrit...

Yep pour les changements proposés, je vais faire ça.

Poser ce nouveau choix anchor_template au dessus de anchor_expression ?

En fait dans le <select> il était déjà au-dessus, donc pas de problème là.

Du côté des libellés j'ai repris sans forcément être tout à fait content des chaines rementionnant "reference date", mais ça pourra toujours s'ajuster à la traduction.