Produits Entr'ouvert » w.c.s.

Après ce patch, il faudra également enchainer sur l'enregistrement dans le formdata de l'info comme quoi telle valeur était vérifiée, pour indiquer ça dans le backoffice pour aider les agents dans le traitement.

Ack sur le patch SAML.

Pourquoi ne pas mettre email aussi dans verified_fields ?

Très mauvais raison mais parce que ça gère la situation particulière de Liège, on a nom/prénom certifiés via carte d'identité mais l'email est libre.

Ack pour le second patch, je remarque juste que dans cette implémentation il est désormais impossible de faire une demande pour un tiers si les champs "demandeurs" sont pré-remplis avec les données du compte et que ces données sont certifiées; pour moi l'implémentation idéale laisserait l'utilisateur modifier la donnée (ou dire qu'il veut faire une demande pour un tiers) mais ce serait au workflow de dire si champs nom, prénom, numéro national d'identité, etc.. == ceux de form.user qui sont validés alors sauter à l'étape suivante.

Ok ack quand même dans la mesure ou le seul utilisateur de ce truc pour l'instant est IMIO.

Yep Benj, ceci étant pour les formulaires ou le bénéfiaire est différent du demandeur, mais où on doit garder l'info "vérifiée" du demandeur, on peut imaginer des formulaires avec une case à cocher "êtes-vous aussi le bénéficiaire", et si non afficher une page qui demande qui est le bénéficiaire.

(autre astuce, préfill python « =form_user_var_.... » et hop)

Donc ça passe. Je relis le patch rapidos.

Yep bien vu, j'aime bien. Reste qu'il faudrait quand même pouvoir réagir au fait qu'un champ est pré-rempli avec une information certifiée et là je ne vois rien, il faudrait une colonne f1_certified ou quelque chose dans ce genre (parce que là à part si le formulaire n'est ouvert qu'aux possesseurs d'une CNIE je ne vois pas trop ce que ça apporte au niveau du traitement de la demande à part d'avoir "readonly" sur le champ.

Oui, c'est mon commentaire :

Après ce patch, il faudra également enchainer sur l'enregistrement dans le formdata de l'info comme quoi telle valeur était vérifiée, pour indiquer ça dans le backoffice pour aider les agents dans le traitement.

Yep, y'a une reflexion a avoir sur ces champs "readonly" qui vont arriver en frontoffice (genre ceux qui pourraient venir d'un calcul =webservice.qf qu'on veut afficher et faire valider à l'usager dans sa demande). A discuter bientôt.

Sinon Ack pour les deux patches.

Juste au cas où, mais je pense que c'est pas important là maintenant : quid du provisionning via hobo ? (genre le cas "extrême" si l'usager est re-provisionné pendant qu'il fait une demande ?).

Ah, quand même, je verrais bien une docstring ou un commentaire sur « def get_prefill_value(self, user=None): » qui précise que le retour attendu est "value (str), verified (bool)"

Thomas Noël a écrit :

Juste au cas où, mais je pense que c'est pas important là maintenant : quid du provisionning via hobo ? (genre le cas "extrême" si l'usager est re-provisionné pendant qu'il fait une demande ?).

La nouvelle valeur sera prise à la volée, silencieusement.