Produits Entr'ouvert » Publik

Stéphane Laget a écrit :

Serait-il possible de contrôler l'affichage des champs dans le résumé de la demande avec le champ "condition" (en mettant par exemple la condition is_in_backoffice) ?

Les conditions d'affichage sur les champs pilotent l'affichage du champ lors de la saisie du formulaire. Il n'y a pas de condition sur l'affichage du champ par la suite : tous les champs saisis font partie de la demande et sont affichés dans le résumé de celle-ci (et on ne peut pas ré-utiliser la notion de condition d'affichage à ce moment).

Quant aux données de traitement, il s'agit comme leur nom l'indique, de données de traitement, et donc ne peuvent être gérées que dans le workflow.

Bref en l'état actuel il n'y a pas de possibilité dans Publik pour ce qui est imaginé ici : c'est un concept vraiment nouveau qui est demandé, qui sort du cadre "la demande" / "son traitement".

Lorsque l'on aborde une réflexion multi-canale (mode guichet, saisie BO, courrier (soyons fous.)..), c'est pourtant un point important.
La personne qui saisie est différente de la personne qui suit la demande sur le FO.
Cependant (tu noteras mon effort de ne pas employer le "en même temps" macronien), est-ce que le fait de prendre en compte les conditions sur les champs dans le réumé de la demande sur le FO a un impact énorme ?
Il y aura-t-il beaucoup d'effets collatéraux non désirés ?

Il y aura-t-il beaucoup d'effets collatéraux non désirés ?

Oui. (imaginons par exemple une page conditionnée par la disponibilité de places)

_~~

Mais peut-on imaginer un truc très simple, comme on a "afficher dans le listing", étendre cette option façon :

reprendre ce champ dans :
  [x] listing backoffice [ ] résumé frontoffice [x] résumé backoffice

Moi j'ai quand même du mal à comprendre... Si ça fait partie de la demande, pourquoi cacher la chose à l'usager ? Après tout, c'est lui qui a donné l'information... Tu as un exemple qui me fera changer d'avis ? ;)

En l'espèce (Grenoble) :
J'ai par ex/ un champ "marquée comme traitée" qui a pour effet de directement fermer la demande en "traitée" dans le WF lorsqu'il est égal à Oui, essentiellement parce que l'information demandée a été donnée au moment de la saisie de la saisie du formulaire.
Souvent la demande doit être "traitée" (ce qui justifie son suivi et donc j'ai dans l'historique un champ : "marquée comme traitée = non" ce qui fait bizarre pour l'usager.

On peut aussi avoir des qualifications "techniques" en fonction de ce que nous raconte l'usager et que l'administration ne veut pas exposer à l'usager (par ex/ Plainte sur la TOEM), si ces champs sont remplis via le formulaire, ils sont alors vus par l'usager.
La solution consistant à les saisir via une étape du WF est coûteuse pour l'agent (temps d'enregistrement, clic supplémentaire...).

Stéphane Laget a écrit :

En l'espèce (Grenoble) :
J'ai par ex/ un champ "marquée comme traitée" qui a pour effet de directement fermer la demande en "traitée" dans le WF lorsqu'il est égal à Oui, essentiellement parce que l'information demandée a été donnée au moment de la saisie de la saisie du formulaire.
Souvent la demande doit être "traitée" (ce qui justifie son suivi et donc j'ai dans l'historique un champ : "marquée comme traitée = non" ce qui fait bizarre pour l'usager.

Il suffit de positiver la chose et ça passe, "Cette demande nécessite un traitement particulier ultérieur : oui/non" et hop.

On peut aussi avoir des qualifications "techniques" en fonction de ce que nous raconte l'usager et que l'administration ne veut pas exposer à l'usager (par ex/ Plainte sur la TOEM), si ces champs sont remplis via le formulaire, ils sont alors vus par l'usager.
La solution consistant à les saisir via une étape du WF est coûteuse pour l'agent (temps d'enregistrement, clic supplémentaire...).

Ok, pigé l'idée.

Reste que c'est quand même un détournement des principes, où une partie du traitement se trouve en fait dans les données de la demande... et un jour on risque de s'en mordre les doigts...

Je ne suis pas très chaud pour bricoler, je serais pour plutôt essayer de creuser une simplification de la saisie. Par exemple les champs conditionnels & co, d'accélérer la saisie de la demande proprement dite (avec l'objectif "tout sur une seule page")...

S'il fallait aller vers une vraie solution, pour moi, ça serait de permettre la saisie de certaines données de traitement, quand on est dans une saisie backoffice.

je plussoie

... Mais la solution proposée par Fred parait plus simple à mettre en oeuvre et répond au besoin.

De mon côté je suis vraiment réticent à l'idée d'ajouter une option sur TOUS les champs pour couvrir une exigence que je n'ai jamais rencontrée et qui me semble apporter de la confusion.

Ne pas saisir dans le formulaire des choses que le demandeur ne doit pas voir, c'est facile à comprendre et ça m'irait assez bien que ça reste comme ça.

Si les agents de Grenoble veulent saisir des infos de traitement dans le formulaire au lieu de le faire là où ça doit être fait (dans l'interface de traitement), ils doivent accepter que les infos soient affichées au demandeur (il me semble possible de travailler pour que ce qui est affiché ne soit pas trop perturbant pour le demandeur).

Le problème n'est pas tellement Grenoble, on leur a expliqué que c'était comme ça, et ils s'y ferront.
Mais pour autant leur argument reste valable.
C'est la prise en compte des spécificités du mode multi-canal qui est en jeu ici, avec l'acceptation du fait que lorsqu'une demande est saisie par un agent pour le compte d'un usager ce n'est pas la même chose que lorsque c'est l'usager qui saisit lui-même la demande.
Aujourd'hui les CT fonctionnant en mode multi-canal avec Publik ne sont pas si nombreuses que ça, mais cela va changer.

Le samedi 08 septembre 2018 à 18:17 +0200, redmine@entrouvert.com a écrit :

Aujourd'hui les CT fonctionnant en mode multi-canal avec Publik ne sont pas si nombreuses que ça, mais cela va changer.

C'est pas faux, je comprends mieux le sens de la demande. Reste que ça m'embête de faire des traitements dans le formulaire.