Projet

Général

Profil

Development #60689

[Inspections des données ] Préciser le destinataire du courriel dans le suivi des actions

Ajouté par Anaïs Ecuvillon il y a environ 2 ans. Mis à jour il y a plus d'un an.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
14 janvier 2022
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

Dans l'inspection des données d'un formulaire, dans le suivi des actions, ce serait bien de préciser quel est le destinataire de l'action Courriel.

Notamment car ici : https://formulaires-landes.test.entrouvert.org/backoffice/management/sylvain-transports/7/inspect, quand il y a 2 actions Courriel à la suite, on ne fait pas la différence.

L'idéal serait un affichage comme dans le schema du workflow genre (https://formulaires-landes.test.entrouvert.org/backoffice/workflows/7/schema.svg)

Courriel (vers Destinataire)
Courriel (vers Usager)


Fichiers

Révisions associées

Révision 0075aaa4 (diff)
Ajouté par Frédéric Péters il y a plus d'un an

backoffice: include action details in tracing inspect section (#60689)

Historique

#1

Mis à jour par Frédéric Péters il y a environ 2 ans

  • Assigné à mis à Frédéric Péters
#2

Mis à jour par Frédéric Péters il y a environ 2 ans

J'ai préféré ne pas reprendre la ligne d'info complète, juste l'info essentielle, sur une action d'email le/s destinataire/s et de manière générale sur les actions qui peuvent avoir un libellé, celui-ci (exemple les actions données de traitement ou appel webservice).

#3

Mis à jour par Thomas Noël il y a environ 2 ans

Ce qui me dérange ici, c'est que si les destinataires de l'action de mail ont été changés entre temps, l'affichage ne va pas correspondre à ce qui avait été effectivement fait par l'action (avant modif). Ça risque un jour de nous induire en erreur.

Là, comme ça, je ne suis pas fan.

On pourrait peut-être enregistrer de l'info au moment de la création du ActionsTracingEvolutionPart : c'est son init qui irait chercher et stocker les get_inspect_details ?

#4

Mis à jour par Frédéric Péters il y a environ 2 ans

On pourrait peut-être enregistrer de l'info au moment de la création du ActionsTracingEvolutionPart : c'est son init qui irait chercher et stocker les get_inspect_details ?

Nope; s'il faut quelque chose de précis, je serais alors pour intégrer les traces réelles des emails (les nouveaux EmailEvolutionPart).

#5

Mis à jour par Thomas Noël il y a environ 2 ans

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

On pourrait peut-être enregistrer de l'info au moment de la création du ActionsTracingEvolutionPart : c'est son init qui irait chercher et stocker les get_inspect_details ?

Nope; s'il faut quelque chose de précis, je serais alors pour intégrer les traces réelles des emails (les nouveaux EmailEvolutionPart).

Note que ce n'est pas tant la précision qui m'importe, qu'une petite cohérence avec l'action existante au moment où elle a été lancée.

Mais oui avec EmailEvolutionPart on pourrait afficher ici quelque chose d'un peu ellipsé, genre :

sans lien vers l'action si celle-ci a été détruite détruite (?).

En tout cas, ça serait mieux, à mon avis.

#6

Mis à jour par Frédéric Péters il y a environ 2 ans

Note que ce n'est pas tant la précision qui m'importe, qu'une petite cohérence avec l'action existante au moment où elle a été lancée.

Il y a déjà réutilisation des id pour les actions; sur une situation de changement de workflow on peut totalement pointer sur des trucs qui ne sont plus ce qui a été exécuté; le seul truc ici serait de pointer vers l'instantané du workflow au moment de l'action, mais ça me semble lourd.

Je serais au final plutôt à soit

  • rejeter sur l'idée qu'on ne veut pas amener une fausse idée,
  • ajouter au patch proposé un encart en haut du suivi des actions "attention ça ne représente pas le workflow tel qu'exécuté mais le workflow tel que présent aujourd'hui"
#7

Mis à jour par Thomas Noël il y a environ 2 ans

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

  • ajouter au patch proposé un encart en haut du suivi des actions "attention ça ne représente pas le workflow tel qu'exécuté mais le workflow tel que présent aujourd'hui"

Bonne idée, en ajoutant «, il peut donc y avoir des incohérences.»

Et c'est très bien ainsi, ça couvre les «incohérences» déjà possibles aujourd'hui (changement de workflow, suppression d'action, de status, etc).

On garde donc le patch proposé, qui est ok ; il faut juste trouver une place pour cet encart.

#8

Mis à jour par Frédéric Péters il y a presque 2 ans

Oublié de reprendre pour ajouter ce message, le voici, après rebase etc.

#9

Mis à jour par Thomas Noël il y a plus d'un an

  • Statut changé de Solution proposée à Solution validée
#10

Mis à jour par Frédéric Péters il y a plus d'un an

  • Statut changé de Solution validée à Résolu (à déployer)
commit 0075aaa4d5e218e188e4320d8dc80722c2a4dd23
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Sun Feb 13 16:32:46 2022 +0100

    backoffice: include action details in tracing inspect section (#60689)
#11

Mis à jour par Transition automatique il y a plus d'un an

  • Statut changé de Résolu (à déployer) à Solution déployée
#12

Mis à jour par Transition automatique il y a plus d'un an

Automatic expiration

Formats disponibles : Atom PDF