Projet

Général

Profil

Development #41919

Permettre la saisie d'adresse en autocomplétion lors de la création et modification de compte

Ajouté par Stéphane Laget il y a presque 4 ans. Mis à jour il y a plus de 3 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
21 avril 2020
Echéance:
30 octobre 2020
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

Sur le modèle de ce qui a été fait pour wcs, permettre ce fonctionnement lors des procédures de création et de modification de compte.

L'échange sur la liste :

Coté implémentation de l'IHM je comptais qu'on attende ce qui est fait coté
w.c.s et recopier ça a la sauce Django, ça évitera d'avoir à réfléchir.
Reste le problème du stockage et de la diffusion, l'idéal pour configurer
ça ce serait que ce soit un type unique de champ (adresse) mais derrière je
n'ai pas d'idée sur comment l'exploiter, pour l'instant nos attributs ne
sont que des chaînes (vu des autres briques, dans A2 on peut stocker du
JSON). Soit on étend le support des attributs (w.c.s., django-mellon,
etc..) pour pouvoir décrire éventuellement au niveau SAML que c'est du JSON :
<saml:AttributeValue xsi:type="eo:json">...</saml:AttributeValue>

c'est un poil ad-hoc mais bon, sinon imaginer une implémentation qui
derrière un unique attribut déclaré génère plusieurs attributs réel au
niveau d'authentic (adresse -> adresse_rue, adresse_numero, etc..) ça fait
plein de code dans authentic beaucoup moins ailleurs (enfin il en faudra
dans hobo pour configurer la diffusion SAML de cet attribut complexe).


Fichiers


Demandes liées

Lié à Intégrations graphiques Publik - Development #47474: Suppression du prefix edit-profile-Fermé08 octobre 2020

Actions

Révisions associées

Révision 7b130d6f (diff)
Ajouté par Lauréline Guérin il y a plus de 3 ans

profile_views: address autocomplete field (#41919)

Historique

#1

Mis à jour par Emmanuel Cazenave il y a presque 4 ans

  • Assigné à mis à Emmanuel Cazenave
#2

Mis à jour par Benjamin Dauvergne il y a presque 4 ans

Ignorer mes considérations sur le transfert de l'adresse comme un tout.

#5

Mis à jour par Brice Mallet il y a plus de 3 ans

  • Echéance mis à 30 octobre 2020
#6

Mis à jour par Lauréline Guérin il y a plus de 3 ans

  • Assigné à changé de Emmanuel Cazenave à Lauréline Guérin
#7

Mis à jour par Frédéric Péters il y a plus de 3 ans

Benjamin peut préciser ses préférences par rapport à la description du ticket, ou peut-être Manu avait déjà regardé ça et vu la direction à prendre.

De mon côté je serais à fuir les modifications de fond et mimer au maximum l'existant w.c.s. : commencer par ajouter un type de champ, genre "autocomplétion d'adresse", qui correspondrait à ce qu'on a dans w.c.s. via https://git.entrouvert.org/wcs.git/tree/wcs/qommon/templates/qommon/forms/widgets/select_jsonp--address.html : un select2 + un input type=checkbox; le select2 serait configuré pour aller chercher les adresses via une URL tapée en settings.

Ensuite le js similaire à https://git.entrouvert.org/wcs.git/tree/wcs/qommon/static/js/qommon.geolocation.js#n58, i.e. on('change'...) qui sur la sélection d'une valeur via le select2 va remplir les champs address/zipcode/city/country (ces noms étant simplement en dur dans le js).

Sur la vue en édition, la même chose, juste en remplissant en amont le select2 avec une adresse reconstituée à partir des données des autres champs.

Ça laisse juste côté w.c.s. à ignorer le nouveau type de champ; ça évite d'avoir à concevoir un nouveau système de champ/donnée complexe dans authentic qui aurait quand même à conserver la compatibilité avec l'existant.

Voilà pour l'approche que j'aurais, qui me semble le meilleur moyen d'obtenir rapidement un résultat ici.

#8

Mis à jour par Benjamin Dauvergne il y a plus de 3 ans

Je n'ai pas d'avis sur l'implémentation, si ça marche pour w.c.s. c'est bon ici aussi (à voir si on peut mutualiser le fichier js ou pas).

Juste sur le point d'ignorer le nouveau type de champ coté w.c.s., dans le cas de Toulouse on voudra stocker l'id (code STI) qu'il retourne, ça me va de se dire qu'on conserve aussi le code BAN ou autre dans les autres cas même si on ne s'en sert pas actuellement.

#9

Mis à jour par Lauréline Guérin il y a plus de 3 ans

  • Tracker changé de Support à Development
#10

Mis à jour par Lauréline Guérin il y a plus de 3 ans

#11

Mis à jour par Frédéric Péters il y a plus de 3 ans

(juste un premier survol), parce que c'est un truc que j'avais noté avant, pour :

+            $('#id_address').val(number_and_street);

sur la page publique de modification du profil (/accounts/edit/), le tag a un id différent, "id_edit-profile-address"; je ne sais pas si ça a un sens et que ça gagnerait juste à être modifié pour avoir partout le même id, ou s'il vaut mieux ajouter un attribut supplémentaire, genre data-attribute-name="address".

#12

Mis à jour par Benjamin Dauvergne il y a plus de 3 ans

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

sur la page publique de modification du profil (/accounts/edit/), le tag a un id différent, "id_edit-profile-address"; je ne sais pas si ça a un sens et que ça gagnerait juste à être modifié pour avoir partout le même id, ou s'il vaut mieux ajouter un attribut supplémentaire, genre data-attribute-name="address".

On peut retirer le préfixe, il du servir dans le passé ou il était prévu qu'il serve mais ce n'est plus le cas. Par contre ça fait quelques tests à modifier à coup de sed (et le edit-profile-next-url aussi).

src/authentic2/views.py:136:        kwargs['prefix'] = 'edit-profile'
src/authentic2/views.py:144:            field_name='edit-profile-next_url',
tests/test_attribute_kinds.py:459:    form.set('edit-profile-first_name', 'John')
tests/test_attribute_kinds.py:460:    form.set('edit-profile-last_name', 'Doe')
tests/test_attribute_kinds.py:461:    form.set('edit-profile-cityscape_image-clear', True)
tests/test_attribute_kinds.py:473:    form.set('edit-profile-cityscape_image', Upload('tests/201x201.jpg'))
tests/test_attribute_kinds.py:483:    assert form['edit-profile-cityscape_image'].attrs['accept'] == 'image/*'
tests/test_profile.py:50:    resp.form['edit-profile-phone'] = '1234'
tests/test_profile.py:51:    assert resp.form['edit-profile-phone'].attrs['type'] == 'tel'
tests/test_profile.py:52:    resp.form['edit-profile-title'] = 'Mrs'
tests/test_profile.py:53:    resp.form['edit-profile-agreement'] = False
tests/test_profile.py:73:    resp.form.set('edit-profile-phone', '0123456789')
tests/test_profile.py:78:    resp.form.set('edit-profile-phone', '9876543210')
tests/test_profile.py:86:    assert 'edit-profile-phone' not in resp.form.fields
tests/test_profile.py:87:    assert 'edit-profile-title' not in resp.form.fields
tests/test_profile.py:88:    assert 'edit-profile-agreement' not in resp.form.fields
tests/test_profile.py:89:    assert 'readonly' in resp.form['edit-profile-phone@disabled'].attrs
tests/test_profile.py:90:    assert resp.form['edit-profile-phone@disabled'].value == '0123456789'
tests/test_profile.py:91:    assert resp.form['edit-profile-title@disabled'].value == 'Mr'
tests/test_profile.py:92:    assert resp.form['edit-profile-agreement@disabled'].value == 'Yes'
tests/test_profile.py:93:    resp.form.set('edit-profile-phone@disabled', '1234')
tests/test_profile.py:94:    resp.form.set('edit-profile-title@disabled', 'Mrs')
tests/test_profile.py:95:    resp.form.set('edit-profile-agreement@disabled', 'False')
tests/test_profile.py:109:    assert 'edit-profile-phone@disabled' not in resp
tests/test_profile.py:110:    assert 'edit-profile-title@disabled' in resp
tests/test_profile.py:111:    assert 'edit-profile-agreement@disabled' in resp
tests/test_profile.py:125:    resp.form.set('edit-profile-phone', '0123456789')
tests/test_profile.py:131:    resp.form.set('edit-profile-phone', '1234')
tests/test_profile.py:156:        return set(key.split('edit-profile-')[1]
tests/test_profile.py:157:                   for key in resp.form.fields.keys() if key and key.startswith('edit-profile-'))
tests/test_profile.py:188:    assert len(response.pyquery('input[type="radio"][name="edit-profile-title"]')) == 2
tests/test_profile.py:189:    assert len(response.pyquery('input[type="radio"][name="edit-profile-title"][readonly="true"]')) == 0
tests/test_profile.py:190:    assert len(response.pyquery('select[name="edit-profile-title"]')) == 0
tests/test_profile.py:195:    assert len(response.pyquery('input[type="radio"][name="edit-profile-title"]')) == 0
tests/test_profile.py:196:    assert len(response.pyquery('input[type="text"][name="edit-profile-title@disabled"][readonly]')) == 1
tests/test_registration.py:382:    assert 'edit-profile-profession' in response.form.fields
tests/test_registration.py:383:    assert 'edit-profile-prenom' not in response.form.fields
tests/test_registration.py:384:    assert 'edit-profile-nom' not in response.form.fields
tests/test_registration.py:386:    assert response.pyquery('[for=id_edit-profile-profession]')
tests/test_registration.py:387:    assert not response.pyquery('[for=id_edit-profile-profession].form-field-required')
tests/test_registration.py:388:    response.form.set('edit-profile-profession', 'pompier')
#13

Mis à jour par Benjamin Dauvergne il y a plus de 3 ans

Et j'oubliais les thèmes :

static/includes/_forms.scss:div.a2-block ul#id_edit-profile-title {
static/minint/initial.css:#id_edit-profile-email_wrap, #id_edit-profile-address_wrap {
static/minint/initial.css:#id_edit-profile-first_name_wrap, #id_edit-profile-phone_wrap, #id_edit-profile-postal_code_wrap {
static/minint/initial.css:#id_edit-profile-last_name_wrap, #id_edit-profile-mobile_wrap, #id_edit-profile-city_wrap {
static/strasbourg-2018/_custom.scss:#id_edit-profile-title li {

bdauvergne@revestel:~/wd/eo/cut-publik-theme$ git grep edit-profile
static/grandlyon-cut/_custom.scss:    ul#id_edit-profile-title li, #registration_completion li {
static/grandlyon-cut/_custom.scss:    ul#id_title, ul#id_edit-profile-title {

#14

Mis à jour par Lauréline Guérin il y a plus de 3 ans

Pour authentic, je regarde les thèmes dans la foulée.
Pour la page accounts/edit, ça donne quelque chose d'un peu étrange si l'un des champ adresse est setté avec le flag verified=True
Est-ce qu'on prévoit quelque chose de particulier pour ce cas ?

#15

Mis à jour par Benjamin Dauvergne il y a plus de 3 ans

Lauréline Guerin a écrit :

Pour authentic, je regarde les thèmes dans la foulée.
Pour la page accounts/edit, ça donne quelque chose d'un peu étrange si l'un des champ adresse est setté avec le flag verified=True
Est-ce qu'on prévoit quelque chose de particulier pour ce cas ?

TL;DR; ne pas s'en préoccuper ni tester ce cas dans ce ticket.

Le principe pour l'instant c'est qu'un champ éditable par l'utilisateur ne l'est plus si il est vérifié. La logique voudrait qu'on flag tous les champs adresse ; le champ autocomplete aussi, donc pas d'interaction entre un autocomplete actif et des champs inactifs. Dans les faits à part GLC qui gère ça totalement différemment on a aucun endroit avec des champs d'adresse vérifiés sauf ceux issus de FranceConnect et l'adresse n'en fait pas partie (indirectement sur Toodego mais le profil vient de GLC et la page d'édition du profil est désactivé).

#18

Mis à jour par Lauréline Guérin il y a plus de 3 ans

#19

Mis à jour par Benjamin Dauvergne il y a plus de 3 ans

  • Statut changé de Solution proposée à Solution validée
#20

Mis à jour par Lauréline Guérin il y a plus de 3 ans

  • Statut changé de Solution validée à Résolu (à déployer)
commit 7b130d6ffc34e1a6b706aa460f1e3ab7a32d5f2a
Author: Lauréline Guérin <zebuline@entrouvert.com>
Date:   Tue Oct 6 15:44:54 2020 +0200

    profile_views: address autocomplete field (#41919)
#21

Mis à jour par Frédéric Péters il y a plus de 3 ans

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF