Projet

Général

Profil

Bug #27795

Cellule "saisie backoffice" pas mise à jour après changement de rôle saisie backoffice dans les formulaires

Ajouté par Pierre Cros il y a plus de 5 ans. Mis à jour il y a plus de 5 ans.

Statut:
Nouveau
Priorité:
Normal
Assigné à:
-
Version cible:
-
Début:
07 novembre 2018
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:

Description

Si on modifie le rôle lié à la saisie backoffice d'un formulaire, la cellule saisie backoffice n'est pas mise à jour (j'ignore la durée du cache) même si on édite/modifie/enregistre la cellule en question. C'est perturbant.

Testé ici : https://agents-lille.test.entrouvert.org/manage/pages/1/


Demandes liées

Lié à Combo - Bug #28043: rafraichir périodiquement les infos de formulaire/catégorie mises en cache dans la dbFermé15 novembre 2018

Actions

Historique

#1

Mis à jour par Frédéric Péters il y a plus de 5 ans

Il y a dix minutes de cache.

On n'a pas de code pour invalider le cache lorsqu'on réenregistre la cellule, je ne sais pas si c'est un comportement implicite qu'on voudrait mettre en place et en avant.

(techniquement, à regarder rapidement, on pourrait y arriver en faisant un appel à .get_data() lors du save() de la cellule, en y acceptant un paramètre invalidate_cache, qu'on passerait ensuite aux appels à requests.get).

#2

Mis à jour par Pierre Cros il y a plus de 5 ans

C'est clairement pas un truc handicapant dans l'usage de Publik pour les gens qui connaissent le fonctionnement du cache. Pour les autres c'est un vrai frein à la compréhension, on les fait douter. La réponse peut être qu'on doit plus insister là-dessus lors des formations d'admins fonctionnels et dans la doc.

#3

Mis à jour par Frédéric Péters il y a plus de 5 ans

Ma question porte plutôt sur la mise en avant d'un comportement "invalidation du cache lorsqu'on clique sur enregistrer", qui n'est pas un comportement qu'on va pouvoir mettre en place partout. Du coup, le faire marcher à certains endroits, en parler pour ces endroits, peut laisser des attentes ailleurs, déçues et insatisfaites. (genre je modifie le texte dans le pied de page, pourquoi il n'apparait pas tout de suite modifié sur une démarche, j'ai pourtant bien cliqué sur "enregistrer").

#4

Mis à jour par Pierre Cros il y a plus de 5 ans

Yep, le fonctionnement, du point de vue de l'UX, devrait être identique pour toutes les cellules Combo.

Sauf erreur, pour la cellule "Démarches d'une catégorie", la mise à jour se fait quand on ré-enregistre la cellule. On s'attend logiquement à la même chose ici.

#5

Mis à jour par Frédéric Péters il y a plus de 5 ans

Sauf erreur, pour la cellule "Démarches d'une catégorie", la mise à jour se fait quand on ré-enregistre la cellule. On s'attend logiquement à la même chose ici.

Pas tout à fait, mais presque, on garde de manière éternelle les informations directement portées par la catégorie (genre son titre), les démarches associées sont récupérées dynamiquement. On a le même type de comportement pour la cellule "lien vers une démarche".

Je ne suis pas fan du comportement "cache éternel faut venir cliquer pour actualiser", c'est plutôt de lui que j'aimerais me défaire.

Qu'on introduise, en parallèle, une autre mécanique, "invalidation du cache au clic sur enregistrer", comme je notais, c'est possible, mais ça introduira des attentes qui ne pourront pas être satisfaites, à d'autres endroits. (exemple du pied de page)

#6

Mis à jour par Frédéric Péters il y a plus de 5 ans

  • Lié à Bug #28043: rafraichir périodiquement les infos de formulaire/catégorie mises en cache dans la db ajouté
#7

Mis à jour par Frédéric Péters il y a plus de 5 ans

Je ne suis pas fan du comportement "cache éternel faut venir cliquer pour actualiser", c'est plutôt de lui que j'aimerais me défaire.

Voilà, avec #28043 ça n'arrive plus, je serais pour maintenant tout à fait désapprendre le "cliquer pour actualiser".

Formats disponibles : Atom PDF