Les suggestions ne sont pas présentées à l'écran lors de l'ouverture du formulaire

[bmo (Bruno Montagnac)]

Request description

Lors de l’initUpdate d’un formularire d’objet métier, je traite des éléments de contexte pour “pousser” des suggestions à l’utilisateur en utilisant l’instruction getContext().addMessage(this, Message.formatSuggestion(code, level, fieldName, suggestedValue), getGrant()). Le message est bien restitué dans l’écran mais pas sous la forme d’une suggestion.

Steps to reproduce

This request concerns an up-to-date Simplicité instance
and these are the steps to reproduce it:

Technical information

Instance /health

---paste the content of your-instance.com/health---

Simplicité logs

---paste the content of the **relevant** server-side logs---

Browser logs

---paste content of the **relevant** browser-side logs---

Other relevant information

----E.g. type of deployment, browser vendor and version, etc.----

[Francois (François Genestin)]

Bonjour Bruno,

Effectivement cela n’a pas dû être prévu, mais ça me semble faisable en passant par la tuyauterie des suggestions à ce niveau. On va regarder.

[Francois (François Genestin)]

@bmo

getContext().addMessage(this, Message.formatSuggestion(code, level, fieldName, suggestedValue), getGrant())

Le contexte en back qui contient des messages ne gérait effectivement pas les suggestions, c’est chose faite.

Sinon côté UI, je me demande si l’affichage du message de la suggestion dans l’entête est pertinente ? A voir si on le garde.

C’est utile pour clicker et mettre le focus sur le champ potentiellement caché, mais en général c’est plus dédié à une anomalie / saisie obligatoire à corriger.

Ce sera livré en 6.1.5

[bmo (Bruno Montagnac)]

D’après ce que j’ai pu expérimenter, seuls les messages de niveau ALERT/ERROR ou WARN sont reportés dans l’entête. Les simple INFO ne le sont pas. ça me semble très bien déjà dans cette configuration.
Mais comme Noël approche, si tu envisages de permettre de spécifier la présentation en HEAD du formulaire (via un flag suppélmentaire dans la spec du message ou tout autre moyen), je prends

[Francois (François Genestin)]

Exact,

Actuellement les messages INFO sont prévus pour être moins intrusifs pour l’utilisateur / présentés en “toast” temporaires et sans interaction UX. Mais parfois on aimerait les rendre plus visibles sans devenir des erreurs/warnings.

On avait aussi dû ajouter un niveau TEXT qui est comme une info mais qui préserve la contenu textuel (dans un <pre>) mais ce n’est pas la même notion, car ça mélange le rendu et le niveau du message.

Voici comment cela pourrait s’améliorer au niveau de la présentation des messages.

Quel que soit le level INFO / WARN / ERROR :

• toast : true | false + flag pinable + duration + location top | bottom + align left | right
• preserve true pour préserver un message textuel (autre que level=TEXT)
• field associé au message + header : true | false pour dupliquer le message du champ dans l’entête

Le front sait déjà gérer par mal de présentations, il faut pouvoir les piloter par les API back.
A suivre.

[bmo (Bruno Montagnac)]