Produits Entr'ouvert » Publik

Frédéric Péters a écrit :

Migrer des anciens sites (avec changement de stockage pour la date)

On parle des champs du profil et donc je pense que les collectivités où on stocke la date de naissance dans le profil sont assez rares. Mais je ne comprends pas les enjeux de la migration et je ne sais pas ce que ça demande comme travail.

ajouter d'autres champs encore (rue avec autocomplétion sur base d'un référentiel)

Ça je trouve que ce serait très utile. On a des incohérences quand on a permis aux gens de se créer un compte avec n'importe quelle adresse et qu'on bloque le remplissage des démarches sur un référentiel d'adresse particulier ensuite. Ça permettait d'utiliser le pré-remplissage en toute quiétude.

Pierre Cros a écrit :

ajouter d'autres champs encore (rue avec autocomplétion sur base d'un référentiel)

Ça je trouve que ce serait très utile. On a des incohérences quand on a permis aux gens de se créer un compte avec n'importe quelle adresse et qu'on bloque le remplissage des démarches sur un référentiel d'adresse particulier ensuite. Ça permettait d'utiliser le pré-remplissage en toute quiétude.

Bémol, un compte citoyen ce n'est pas forcément quelqu'un qui habite dans le coin, adresse pas forcément connue du référentiel des rues du SIG de la commune. Il faut donc conserver de la souplesse.

Je veux bien bosser sur un champ rue voir un champ structuré adresse mais j'aimerai ne pas le faire de plusieurs manière différentes (une fois pour le SIG de telle ville, une fois pour la BANO, etc..). On a une politique là dessus ?

• j'ajouterai le support du kind à hobo si ce n'est pas déjà le cas
• je modifierai le profil de base pour faire en sorte que date de naissance ou code postal utilisent les bons kind
• je ne permettrai pas de modifier un profil existant dans un premier temps

Les nouveaux types seront pour les nouveaux déploiements, pour les clients existant demandant la gestion des dates on pourra commencer par faire la migration à la main. c'est stocké au format 'Y-m-d'), il faudra dans un premier tout mettre dans ce format là, virer ce qui ne correspond pas du tout puis il suffit de changer le kind dans hobo et authentic2.

Benjamin Dauvergne a écrit :

Je veux bien bosser sur un champ rue voir un champ structuré adresse mais j'aimerai ne pas le faire de plusieurs manière différentes (une fois pour le SIG de telle ville, une fois pour la BANO, etc..). On a une politique là dessus ?

Le référentiel en France devrait être la BAN mais n'est pas utilisé partout et beaucoup de villes préféreront utiliser leur propre référentiels (qui peuvent être dans le SIG, fournis dans une table à plat pour un référentiel de voies... cf. Nancy - je crois, Nanterre, Grenoble...)
De plus des adresses hors France possible.
Plus globalement, mettrait on en place un référentiel de voies ou d'adresses ?
À mon avis, il ne peut pas y avoir une réponse unique pour tous nos clients mais si on doit utiliser UN référentiel, alors c'est clairement la BAN à charge pour nos clients de l'accepter, sinon payer pour un développement qui leur sera propre

Ma position avant même ce ticket c'est que le format d'adresse en entrée d'un système doit être le plus fin possible pour permettre facilement le reformatage (dans l'autre sens c'est vraiment dur). De ce que je retiens des commentaires c'est qu'on doit pouvoir viser la BANO ou la BAN via le connecteur passerelle compatible BANO et ou le SIG d'une ville (via un connecteur passerelle compatible avec l'API BANO aussi) mais uniquement en mode aide à la saisie, sans contrainte.

• pouvoir désigner l'URL d'une API compatible BANO, avec des restriction sur pays/code postal,
• pouvoir indiquer un pays / code postal par défaut,
• avoir un champ d'adresse complet et stocker ça de manière structurée avec un champ pays (par défaut à France), un champ bis/ter/machin, un champ complément ("Chez Monsieur Truc")
• avoir une aide à la saisie qui se débraye et s'appuie sur les champs code postaux/pays pour taper dans la bonne API,
• au niveau SSO pouvoir fournir ça dans un autre format (pour s'adapter)

Quelque chose qui vous dérange dans cette roadmap ?

Pour l'existant soit on peut migrer soit on ne peut pas :)

Un petit avis sur le sujet: attention à ne pas faire croire à l'usager que s'il modifie son adresse dans Authentic, alors la ville est au courant de son déménagement...

Pour ma part, et pour faire diverger ce ticket, je reste convaincu que cette adresse dans le profil ne sert à rien dans la vraie vie des gens ; et uniquement à la mairie pour faire son flicage. Je passerais plus de temps à étudier comment faire du numéro de téléphone portable un identifiant du même niveau que le mail (je vous avais prévenu que j'allais diverger)