Bug #9705
Option d'affichage "afficher sur …" sur l'action "afficher un message"
80%
Description
(reprise de #1231 qui avait dérivé ; reprise dans le cadre Alfortville)
L'action "afficher un message" est prévue pour un affichage frontoffice, mais elle s'exécute aussi en backoffice, ce qui peut perturber les agents traitants (message complétement hors contexte). D'un autre côté, on aimerait pouvoir afficher des message uniquement en backoffice, justement pour guider les agents.
Je propose l'ajout d'une option "Afficher sur …" qui aura trois choix : "le frontoffice", "le backoffice", "les deux" -- ce dernier choix étant celui par défaut (et c'est le choix actuel).
Fichiers
Révisions associées
Historique
Mis à jour par Thomas Noël il y a plus de 8 ans
Fred : « a priori je dirais que je préférerais qu'on définisse le public (/rôle) du message plutôt que l'endroit où il doit s'afficher. »
Mis à jour par Frédéric Péters il y a plus de 8 ans
Plutôt que le paramétrage de l'endroit où le message s'afficherait je serais pour qu'on puisse paramétrer le public (e.g. les rôles).
Mis à jour par Thomas Noël il y a plus de 8 ans
Après étude sur un cas réel avec Brice, ça n'ira pas dans le cas où on veut qu'un message affiché sur le front (au "utilisateurs connectés") ne s'affiche pas en backoffice (ou tous les utilisateurs sont connectés...) c'était une bétise, cf ci-dessous
Mis à jour par Frédéric Péters il y a plus de 8 ans
Il ne faut pas utiliser "Utilisateurs connectés" (surtout que ça pourrait bien ouvrir l'accès à la demande à tout le monde); il faut utiliser "Usager".
Mis à jour par Thomas Noël il y a plus de 8 ans
- Fichier 0001-workflows-add-target-roles-in-display-message-workfl.patch 0001-workflows-add-target-roles-in-display-message-workfl.patch ajouté
Je ne parviens pas à faire des tests sans artifices bizarres, je dois mal m'y prendre. Le patch n'est donc pas fini.
Concernant le code lui-même:- j'ai utilisé un attribut "to" comme pour les mails
- avant, un status ne pouvait contenir qu'un seul "afficher un message", seul le premier était affiché ; maintenant, tous les messages (qui doivent l'être) sont affichés [ça peut être discuté mais ça me semble mieux de faire ainsi, plus logique qu'avant]
- cela modifie l'HTML rendu en backoffice en ajoutant systématiquement des <p>...</p> pour chaque message, y compris s'il y en a un seul
Mis à jour par Thomas Noël il y a plus de 8 ans
- Statut changé de Nouveau à En cours
- Patch proposed changé de Non à Oui
(patch proposed mais pas bon)
Mis à jour par Thomas Noël il y a plus de 8 ans
- Fichier 0001-workflows-add-target-roles-in-display-message-workfl.patch 0001-workflows-add-target-roles-in-display-message-workfl.patch ajouté
- % réalisé changé de 0 à 80
Vu avec Fred, des tests plus clean. Reste à faire le tour des possibilités dans ces tests pour valider le truc.
(Note : j'ai déjà testé sur un wcs local, tout semble ok, donc vous pouvez quand même déjà vous mettre à lire le beau patch)
Mis à jour par Thomas Noël il y a plus de 8 ans
- Fichier 0001-workflows-add-target-roles-in-display-message-workfl.patch 0001-workflows-add-target-roles-in-display-message-workfl.patch ajouté
Voilà, avec un certain nombre de tests. Cette fois, ack qui peut.
Mis à jour par Frédéric Péters il y a plus de 8 ans
"def workflow_messages" je renommerais en get_workflow_messages (l'occurence dans formdata.py).
Pour l'import/export des rôles c'est un peu plus compliqué que ça, il ne faut pas juste exporter l'id mais les noms aussi. (il y a _roles_export_to_xml et _roles_init_with_xml pour aider).
Ce serait bien d'avoir un test dans test_form_pages.py pour vérifier la présence sur la page du texte.
Ce serait un changement par rapport au comportement actuel mais les différents messages je les verrais bien dans un <div id="receipt-intro">, comme l'est le texte quand il n'y a pas de workflow_messages.
Mis à jour par Thomas Noël il y a plus de 8 ans
- Fichier 0001-workflows-add-target-roles-in-display-message-workfl.patch 0001-workflows-add-target-roles-in-display-message-workfl.patch ajouté
Frédéric Péters a écrit :
"def workflow_messages" je renommerais en get_workflow_messages (l'occurence dans formdata.py).
Ok.
Pour l'import/export des rôles c'est un peu plus compliqué que ça, il ne faut pas juste exporter l'id mais les noms aussi. (il y a _roles_export_to_xml et _roles_init_with_xml pour aider).
Selon moi c'est déjà pris en charge par WorkflowStatusItem (to_export_to_xml et to_init_with_xml).
Ce serait bien d'avoir un test dans test_form_pages.py pour vérifier la présence sur la page du texte.
Carrément, j'ai ajouté ça.
Ce serait un changement par rapport au comportement actuel mais les différents messages je les verrais bien dans un <div id="receipt-intro">, comme l'est le texte quand il n'y a pas de workflow_messages.
C'est fait aussi, mais pour respecter un peu ce nommage "intro" je me suis permis de modifier l'affichage backoffice : les messages affichés le seront en haut de page (et non pas entre le résumé et le journal comme actuellement, ce qui était un peu bizarre de toute façon, àmha).
Mis à jour par Thomas Noël il y a environ 8 ans
- Statut changé de En cours à Résolu (à déployer)
- Version cible mis à v1.32
commit 176415b71605c269ae1668ec22ead52b0be22ae5
Author: Thomas NOEL <tnoel@entrouvert.com>
Date: Fri Jan 22 19:16:09 2016 +0100
workflows: add target roles in display message workflow item (#9705)
workflows: add target roles in display message workflow item (#9705)