Project

General

Profile

Development #33862

action globale nécessairement python (?)

Added by Frédéric Péters 2 months ago. Updated about 2 months ago.

Status:
Solution proposée
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
12 Jun 2019
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No

Description

D'un mail :

Mais c'est mieux de faire une action globale qu'un statut pour ça et pour les
actions globales c'est nécessairement Python.

À creuser on ne devrait imposer Python nulle part.

0001-workflows-add-support-for-django-template-as-anchor-.patch View (4.11 KB) Frédéric Péters, 30 Jun 2019 05:23 PM

0001-workflows-add-support-for-django-template-as-anchor-.patch View (3.53 KB) Frédéric Péters, 01 Jul 2019 09:24 AM

History

#1 Updated by Pierre Cros 2 months ago

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

#2 Updated by Frédéric Péters about 2 months ago

Option prise ici d'offrir uniquement une option "Expression", qui accepte python ou django, ça peut se discuter.

#3 Updated by Pierre Cros about 2 months ago

ça me va tellement bien que ce serait bien que ce soit comme ça partout ou on peut écrire du code en fait (j'imagine que c'est pas tellement possible) :
  • Expression (ça prend du Python ou du Django)
  • Gabarit

#4 Updated by Frédéric Péters about 2 months ago

Patch qui plutôt crée une nouvelle option "Texte / gabarit", pour se rapprocher de ce qui se fait ailleurs, pour permettre des évolutions communes ensuite.

#5 Updated by Thomas Noël about 2 months ago

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.

#6 Updated by Frédéric Péters about 2 months ago

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

#7 Updated by Thomas Noël about 2 months ago

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.

Also available in: Atom PDF