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).
Files
Associated revisions
History
Updated by Thomas Noël about 7 years ago
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. »
Updated by Frédéric Péters about 7 years ago
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).
Updated by Thomas Noël about 7 years ago
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
Updated by Frédéric Péters about 7 years ago
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".
Updated by Thomas Noël about 7 years ago
- File 0001-workflows-add-target-roles-in-display-message-workfl.patch 0001-workflows-add-target-roles-in-display-message-workfl.patch added
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
Updated by Thomas Noël about 7 years ago
- Status changed from Nouveau to En cours
- Patch proposed changed from No to Yes
(patch proposed mais pas bon)
Updated by Thomas Noël about 7 years ago
- File 0001-workflows-add-target-roles-in-display-message-workfl.patch 0001-workflows-add-target-roles-in-display-message-workfl.patch added
- % Done changed from 0 to 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)
Updated by Thomas Noël about 7 years ago
- File 0001-workflows-add-target-roles-in-display-message-workfl.patch 0001-workflows-add-target-roles-in-display-message-workfl.patch added
Voilà, avec un certain nombre de tests. Cette fois, ack qui peut.
Updated by Frédéric Péters about 7 years ago
"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.
Updated by Thomas Noël about 7 years ago
- File 0001-workflows-add-target-roles-in-display-message-workfl.patch 0001-workflows-add-target-roles-in-display-message-workfl.patch added
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).
Updated by Thomas Noël about 7 years ago
- Status changed from En cours to Résolu (à déployer)
- Target version set to 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)