Project

General

Profile

Development #71430

Saut automatique : possibilité de préciser une date

Added by Pierre Ducroquet 14 days ago. Updated 8 days ago.

Status:
Rejeté
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
17 November 2022
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

On observe a minima un cas où notre mécanique d'expiration est insuffisante pour répondre complètement à un besoin et est complétée par une condition pour spécifier une date. On est donc obligés de charger et d'évaluer inutilement l'ensemble des données, tout en ayant au final un système moins clair pour l'utilisateur.

History

#2

Updated by Frédéric Péters 14 days ago

"une date" : entendu vraiment comme une date, c'est-à-dire un workflow où il serait noté 17/11/2022 ?

(à suivre les liens, oui, là il y a vraiment un workflow qui met en dur "2023-06-30").

Ça m'a l'air globalement farfelu, à un point où en fait ça ne fonctionnera quasi jamais : la date ne sera généralement pas mise ainsi dans le workflow mais dans une option et donc il y aura gabarit à évaluer, et donc fin du game.

#3

Updated by Pierre Ducroquet 14 days ago

Je comprends l'argument que ça semble farfelu, mais Brice semblait dire qu'il avait déjà eu le besoin, et si on a au moins cette possibilité affichée dans l'interface, même si tout le monde ne l'utilisait pas, le peu de cas sera toujours bénéfique par rapport au volume de calculs inutiles dans le cas contraire.

#4

Updated by Frédéric Péters 14 days ago

  • Status changed from Nouveau to Information nécessaire
  • Assignee set to Brice Mallet

Je suis pour renforcer/automatiser la détection des situations problématiques mais vraiment je ne crois pas à l'option très limitée/spécifique ici.

mais Brice semblait dire qu'il avait déjà eu le besoin

(détails nécessaire)

#5

Updated by Pierre Cros 14 days ago

Ce qui permettrait de clarifier les expirations m'intéresse (même si j'ai bien compris que le but premier du ticket c'est de diminuer le volume de calcul).

Cela étant, contrairement à Brice, je n'ai jamais eu besoin de mettre une date fixe dans un saut auto

#6

Updated by Thomas Noël 13 days ago

Pierre Cros a écrit :

Cela étant, contrairement à Brice, je n'ai jamais eu besoin de mettre une date fixe dans un saut auto

Et pour ma part je rejoins finalement Frédéric, ça ne sera jamais le cas en réalité, on aura plutôt quelque chose comme

{{ form_option_date_de_bascule }}

et jamais une date fixe perdue au fin fond de la configration d'un saut dans un workflow.

#7

Updated by Benjamin Dauvergne 13 days ago

Thomas Noël a écrit :

Et pour ma part je rejoins finalement Frédéric, ça ne sera jamais le cas en réalité, on aura plutôt quelque chose comme

{{ form_option_date_de_bascule }}

et jamais une date fixe perdue au fin fond de la configration d'un saut dans un workflow.

Ça change quoi que la date soit fixe ou variable ? Si l'objectif c'est d'avoir une colonne "next_expiration" et y mettre une date pour savoir quand réveiller la demande plutôt que de la tester à chaque réveil du cron, c'est pareil (maintenant je m'avance peut-être un peu sur l'implémentation technique envisagée).

#8

Updated by Frédéric Péters 13 days ago

Ça change quoi que la date soit fixe ou variable ?

Si c'est un gabarit ça veut dire qu'il faut le calculer, et que le résultat peut varier selon les demandes, qu'il faut donc passer sur toutes les demandes/fiches.

#9

Updated by Benjamin Dauvergne 13 days ago

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

Ça change quoi que la date soit fixe ou variable ?

Si c'est un gabarit ça veut dire qu'il faut le calculer, et que le résultat peut varier selon les demandes, qu'il faut donc passer sur toutes les demandes/fiches.

Pour une demande donnée le résultat ne peut pas varier sauf si il dépend de quelque chose qui n'est pas dans le formdata, c'est peut-être ça qu'il faudrait pouvoir détecter et réévaluer à chaque formdata.store(), une date du genre {{ form_last_update_time|add_days:10 }} on peut en stocker la valeur dans une colonne expiration si c'est recalculé à chaque formdata.store(), on est sûr que ça va marcher (et sur une modification du gabarit dans le workflow il faut repasser sur toutes les demandes dans le statut correspondant mais ce n'est pas pire que maintenant).

Je ne dis pas que c'est simple de ne plus tester systématiquement les sauts automatiques avec condition dans tous les cas. Mais on doit pouvoir progressivement extraire les cas "simples" en étant prudent : les conditions et expirations qui ne dépendent que du dernier statut et de l'état courant de la demande (typiquement la présence d'un webservice.* rend ça faux), pour une condition simple, si elle est fausse maintenant elle le sera toujours dans le futur si la demande n'est pas modifiée entre temps. Et pour une date d'expiration elle ne changera pas, elle peut donc être stockée et servir de filtre.

Ça marcherait d'ailleurs bien avec les triggers aussi, sur un trigger la demande est modifiée et le statut de toutes les conditions réévaluées (en posant un formdata.expiration = now() pour que la demande soit considérée à la prochain boucle par exemple).

#10

Updated by Brice Mallet 12 days ago

  • Status changed from Information nécessaire to Nouveau
  • Assignee deleted (Brice Mallet)

Et pour ma part je rejoins finalement Frédéric, ça ne sera jamais le cas en réalité, on aura plutôt quelque chose comme {{ form_option_date_de_bascule }}

Comparaison à une date, qu'elle soit en dur ou dans une variable de WF (il faudra encourager la variable, certainement pour des questions de maintenance) est le cas : année scolaire, date de commission, date max pour déposer une demande de sub...

#11

Updated by Frédéric Péters 12 days ago

il faudra encourager la variable

C'est mon propos : on n'encouragera pas de date fixe, on sera sur un gabarit, et ça ne fait au final donc pas de différence (de calcul) par rapport à la condition django.

Reste ce que Benjamin écrit, « on doit pouvoir progressivement extraire les cas "simples" en étant prudent » mais ça peut totalement passer sans ajouter une "possibilité de préciser une date". Et ça n'est donc pas ce ticket.

#12

Updated by Frédéric Péters 9 days ago

  • Status changed from Nouveau to Rejeté

Et donc, non.

#13

Updated by Benjamin Dauvergne 8 days ago

« mais ça peut totalement passer sans ajouter une possibilité de préciser une date". »

Pas sûr.

Parce qu'autant c'est simple de dire, dans le cas :
  • Quand: Toutes les 20 minutes
  • Condition: form_var_truc "Oui"
    que si la condition est fausse est fausse maintenant elle le sera encore dans 20 minutes et donc pas la peine de programmer un test de la demande dans 20 minutes.
Pareil pour :
  • Quand: Toutes les 20 minutes
  • Condition: webservice.truc.machin "Oui"

De la présence de webservice on peut déduire qu'on ne peut rien savoir et donc on se tapera un test toutes les 20 minutes.

Autant analyser ça :
  • Quand: Toutes les 20 minutes
  • Condition: form_var_truc == "Oui" and form_var_date|date|add_days:30 <= today|date

pour en déduire qu'il faut programmer le test de la demande dans 30j c'est une analyse plus compliqué

Alors si on pouvait directement le remplacer par:
  • Quand: {{ form_var_date|date|add_days:30 }}
  • Condition: form_var_truc == "Oui"

je crois qu'on gagnerait un cas simple facilement.

Also available in: Atom PDF