Produits Entr'ouvert » w.c.s.

C'est bien ça l'idée.

D'une lecture rapide j'ai l'impression :

• qu'il y a un changement de comportement quant au id_display
• que le truc sur le changement d'utilisateur loggué, je le comprends pas

(et le flatten_dict, il y aurait moyen de mettre en commun avec celui dans wcs/formdata.py ?)

Ça me parait pas du tout générique de lier ça aux appels de WS. On pourrait pas simplement avoir une action "Set user field" qui pourrait reprendre une variable dans les données du workflow (dont par exemple les données issue d'un appel de WS) et pousser ça dans un utilisateur ?

Ça me parait pas du tout générique de lier ça aux appels de WS. On pourrait
pas simplement avoir une action "Set user field" qui pourrait reprendre une
variable dans les données du workflow (dont par exemple les données issue
d'un appel de WS) et pousser ça dans un utilisateur ?

Après 30 secondes de reflexion, je suis plutôt très beaucoup d'accord. Disons
une action de workflow qui s'appelerait "ajout de données sur un
utilisateur". Avec un WidgetDict.

Plutôt que WidgetDict il faudrait ajouter à TableWidget la gestion d'un nombre de lignes dynamiques (ou de colonne si ça coûte pas plus cher ;) ), c'est un peu la seule chose qui fait utiliser un WidgetDict plutôt qu'un TableWidget. Il y a aussi le fait de pouvoir utiliser autre chose qu'un StringWidget mais là on n'est pas concerné.

Ensuite on pourra virer WidgetDict.

Je me répond à moi même il y a le TableListRowsWidget qui semble faire l'affaire ;-)

Qu'en pensent Victor et Pierre ? (vu que ce sont particulièrement eux qui créent des workflows, font les formations et la doc)

Ok, à en discuter avec Pierre il n'y a pas de cas d'usage clair pour lui, "je relie le compte à un système externe" le fait penser à de la fédération et du coup il se demande ce que ça fout là.

Pour aider à la compréhension de la fonctionnalité, il y aurait moyen de déjà décider d'un nom pour l'action ("Affecter un paramètre à l'usager" ? (bof)), et de la décrire en deux ou trois paragraphes, d'éventuellement donner un autre cas où elle serait utile ? (Ça pourra ensuite servir pour la doc)

Ou pas, et on fait juste le code ainsi, parce qu'il y a en a besoin là pour Orléans, et basta ? (option que j'aime moins bien, mais que je comprendrais)

Le 25/11/2013 15:36, redmine@entrouvert.com a écrit :

La demande #3988 a été mise à jour par Frédéric Péters.
Pour faire cela, je propose d'ajouter un second nom de variable paramétrable lors de l'appel webservice. Si ce nom de variable est défini, alors le retour du webservice sera enregistré dans user.workflow_data.

Le cas typique c'est de relier un identifiant métier au compte dans
w.c.s. On peut appeler ça de la fédération si on veut, pas de problème,
mais ça n'a rien à faire dans authentic, c'est bien lié à w.c.s et à une
problématique métier.

Benjamin Dauvergne a écrit :

Le cas typique c'est de relier un identifiant métier au compte dans
w.c.s. On peut appeler ça de la fédération si on veut, pas de problème,
mais ça n'a rien à faire dans authentic, c'est bien lié à w.c.s et à une
problématique métier.

J'entends ça très bien, et je suis sûr que Thomas, toi et moi, on est d'accord là-dessus; reste que les fonctionnalités on les écrit aussi pour les autres utilisateurs et il est donc utile d'en avoir une présentation claire.

Le 25/11/2013 18:04, redmine@entrouvert.com a écrit :

La demande #3988 a été mise à jour par Frédéric Péters.

Benjamin Dauvergne a écrit :

Le cas typique c'est de relier un identifiant métier au compte dans
w.c.s. On peut appeler ça de la fédération si on veut, pas de problème,
mais ça n'a rien à faire dans authentic, c'est bien lié à w.c.s et à une
problématique métier.

J'entends ça très bien, et je suis sûr que Thomas, toi et moi, on est d'accord là-dessus; reste que les fonctionnalités on les écrit aussi pour les autres utilisateurs et il est donc utile d'en avoir une présentation claire.

En dehors des WS ça peut aussi servir à faire des traitements avec état
qui nécessitent plusieurs formulaires et qui ne seraient pas encore
gérés par des rôles. Exemple: attribution d'un taux de réduction
quelconque (quotient familial) pour de la facturation, dans un premier
formulaire qu'on réutilise ensuite dans un formulaire d'achat de tickets
de cantines.

Donc, récapitulons : le système proposé par Benj (variables hors de l'appel ws) permet d'attribuer des valeurs à un usager, disponibles via des variables de substitution.

Exemple : dans un workflow, l'agent vérifie que l'usager a des enfants et calcule son quotient familial. Il met l'utilisateru dans le rôle "personne avec enfant", rempli un formulaire backoffice avec le quotient choisi, et ce dernier est stocké dans "user_var_qf" disponible ensuite partout où nécessaire.

C'est ce dernier stockage que l'action proposée par Benjamin permet. Ca n'a pas forcément de rapport avec une appli externe, c'est juste une info dont on veut pouvoir profiter plus tard, dans d'autres traitements, etc...

Autre exemple : un compte "gérant entreprise". La personne aura le rôle "gérant entreprise" et on ajoute le SIRET (et autres infos) dans les données de l'usager, pour du pré-remplissage des formulaires liés à la vie de sa boite.

Autre possibilité : j'ai un champ "adresse" pour chaque utilisateur (avec la variable user_var_adresse). On peut imaginer que l'action de workflow permette de modifier cette valeur (le "vrai" champ du compte de l'utilisateur) si c'est la variable "adresse" qui est modifiée. On peut donc avoir des formulaires très customisés (en fonction du rôle, par exemple) pour mettre à jour un compte.

Enfin, dernier avantage : à Orléans je n'ai finalement pas besoin de ce principe, je fais autrement en appelant systématiquement des webservices pour afficher, par exemple, le numéro de la famille lié à la personne. Mais c'est lourd, et si passerelle bloque un peu à ce moment là, c'est lent et ça peut même planter (timeout). L'usage d'un simple user_var_idfamille aurait été plus parlant.