Produits Entr'ouvert » Authentic 2

Même si la recherche ne se base que sur nom et prénom, il est important d'afficher sur les lignes des résultats d'invalidation l'ensemble des attributs (dans l'ordre de déclaration dans A2) et infos dispos sur chaque utilisateur trouvé :

• prénom1 nom1 <email1> date-de-naissance - adresse - attribut - attribut ... [créé le ... - dernière activité le ...]
• prénom2 nom2 <email2> date-de-naissance - adresse - attribut - attribut - ... [créé le ... - dernière activité le ...]

ça permet de voir s'il s'agit de la même personne que celle qu'on cherche à créer sans forcément avoir à cliquer pour avoir les détails (on les voit déjà à 90%)

Valentin Deniaud a écrit :

Aussi dans ton screen tu inclus les attributs adresse, ici c'est inutile vu que pour l'instant ils ne sont pas pris en compte dans la recherche. Par contre inclure la date de naissance, pourquoi pas, mais je ne sais pas trop comment faire (la partie user.attributes.birthdate, ok, mais quelle condition pour vérifier qu'un tel attribut existe et ne pas crasher salement le template).

Je dirais que {% if form.cleaned_data.birthdate and user.attributes.birthdate %}...{% endif %} ne devrait pas cracher, ou alors attributes a un souci à corriger (il devrait lever un AttributeError si pas présent, gentiment ignoré par le template).

Par rapport aux remarques de Thomas je mettrais un target="_blank" sur les liens sinon les gens vont jurer après avoir cliqué (parce qu'il me semble qu'il y a plus de gens qui savent fermer un onglet plutôt qu'utiliser le bouton Back, mais ça se discute).

Benjamin Dauvergne a écrit :

(parce qu'il me semble qu'il y a plus de gens qui savent fermer un onglet plutôt qu'utiliser le bouton Back, mais ça se discute).

Les agents ne sont pas plus doués pour se retrouver avec des onglets que les usagers lambda... laissons les target tranquilles :)

Thomas Noël a écrit :

Les agents ne sont pas plus doués pour se retrouver avec des onglets que les usagers lambda... laissons les target tranquilles :)

Si on trouve un outil pour faire des formulaires, à l'occasion je ferai bien un sondage :)

Valentin Deniaud a écrit :

Benjamin Dauvergne a écrit :

Je dirais que {% if form.cleaned_data.birthdate and user.attributes.birthdate %}...{% endif %} ne devrait pas cracher, ou alors attributes a un souci à corriger (il devrait lever un AttributeError si pas présent, gentiment ignoré par le template).

Effectivement c'est moi qui oubliait qu'on s'en foutait des AttributeError dans un template.
Mais pas la peine finalement, je pars sur l'affichage de tous les attributs sans distinction.

Par rapport aux remarques de Thomas je mettrais un target="_blank" sur les liens sinon les gens vont jurer après avoir cliqué (parce qu'il me semble qu'il y a plus de gens qui savent fermer un onglet plutôt qu'utiliser le bouton Back, mais ça se discute).

Je vote en faveur du bouton back, Thomas pourra nous départager si il a envie !

      <a href="{% url 'a2-manager-user-detail' pk=user.pk %}">{{ user.get_full_name }}</a> {{ user.email }}
      {% for attribute in user.attribute_values.all %}
      {% if attribute.content and attribute.attribute.name != "first_name" and attribute.attribute.name != "last_name" %}
      - {{ attribute.content }}
      {% endif %}
      {% endfor %}

1. J'en ferais un template à part qu'on puisse le surcharger sans toucher à tout ça {% include "authentic2/manager/user-create-duplicate.html" with user=user %}
2. On a aucune idée de l'ordre ou du contenu des attributs, il ne faut pas les afficher comme ça, à la rigueur l'attribut nommé birthdate comme je l'ai montré et que s'il était présent lors de la recherche, mais de toute façon si on veut faire mieux on le fera au niveau du thème Publik;
3. J'aurais mis la suggestion de Thomas sur la date de création et dernier login, ça on est sûr que ça existe et c'est pertinent pour différencier des doublons.

Pour la date de naissance aussi ça serait bien d'avoir une traduction à la « Birthdate: {{ date }} »

Pourquoi ne pas afficher l'adresse ? On connait l'ordre des attributs dans Authentic, non ?

Benjamin Dauvergne a écrit :

Mouais bof ça donnera un truc moche en général parce qu'il y a n'importe quoi dans les adresses (les gens remplissent sans savoir à quoi ça sert je pense, et quand ça pré-remplit n'importe quoi ils corrigent le formulaire directement mais jamais leur profil parce qu'ils ne savent pas que ça existe), mais si tu penses très fort au Nord, pourquoi pas :

Je voulais juste m'éviter un paramétrage caché au fin fond de publik-base-theme. Tant pis.

Thomas Noël a écrit :

Je voulais juste m'éviter un paramétrage caché au fin fond de publik-base-theme. Tant pis.

Je proposais le bout de template pour que Valentin l'inclut par charité chrétienne, pas pour te pousser à ouvrir un ticket sur publik-base-theme macarel!

Thomas Noël a écrit :

Pourquoi ne pas afficher l'adresse ? On connait l'ordre des attributs dans Authentic, non ?

Je pense que soit on itère sur tous les attributs et on les affiche comme j'avais fait, mais à ce moment là on se retrouve avec des lignes de taille imprévisible potentiellement très moches, soit on affiche rien (enfin, juste birthdate, mais c'est déjà borderline). Tout ça pour reporter à publik-base-theme le soin d'afficher joliment les attributs connus posés par hobo (ce qu'il n'est pas possible de faire dans un template a2, parce qu'on n'a aucune idée des noms des attributs et c'est pas beau de les guesser).

ce qu'il n'est pas possible de faire dans un template a2, parce qu'on n'a aucune idée des noms des attributs

Mais euh ? Authentic connait totalement les attributs des utilisateurs, il les présente sur la page dans le bon ordre, etc.

Ma position serait d'afficher côte à côte, prénom/nom puis, séparés par des tirets, tous les attributs qualifiés de "searchable" :

ex: Frédéric Péters - fpeters@entrouvert.com - rue de Liedekerke 82 - 1210 - Bruxelles (i.e. comme la capture/maquette)

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

ce qu'il n'est pas possible de faire dans un template a2, parce qu'on n'a aucune idée des noms des attributs

Mais euh ? Authentic connait totalement les attributs des utilisateurs, il les présente sur la page dans le bon ordre, etc.

Par « connaître » j'entends bien sûr « appeler par son nom », type user.attributes.address tapé plus haut. À partir du moment où on peut boucler genre sur

tous les attributs qualifiés de "searchable"

C'est bon, mais c'est modulo le searchable ce que j'avais fait plus haut dans le ticket, un pas en avant/un pas en arrière, ça me paraissait un bon moyen de faire avancer le truc que de déporter les discussions de la tête que ça devait avoir dans publik-base-theme.

la tête que ça devait avoir dans publik-base-theme

publik-base-theme c'est bien pour permettre des points qu'on ne souhaiterait pas dans authentic, mais avoir une solution bonne pour tout le monde directement dans authentic, ça doit quand même rester l'objectif.

Donc pour moi, de base un gabarit dans authentic, qui affiche comme j'écrivais. (+ la date de création qui a été notée comme étant utile aussi).

Mais de Benjamin :

{% for attribute in user.attribute_values.all %}
2. On a aucune idée de l'ordre ou du contenu des attributs (...)

Ça veut peut-être dire qu'il manque le nécessaire pour boucler sur les attributs dans le bon ordre ? (qui serait à ajouter)

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

Ça veut peut-être dire qu'il manque le nécessaire pour boucler sur les attributs dans le bon ordre ? (qui serait à ajouter)

Au passage : dans l'API de recherche des doublons, pour chaque usager trouvé on renvoie un "text" qui est actuellement juste le nom complet. On devrait en réalité renvoyer ce qu'on projette ici. Et donc, je me dis que c'est dans la fonction find_duplicates qu'il faudrait générer l'information « text = full_name - email - attributs - date de création - date de dernier login », et elle serait utilisée ici.

tous les attributs qualifiés de "searchable"

Plutôt tous les attributs affichés à l'usager. Le fait qu'un attribut soit "searchable" ne veut pas dire qu'il permet de distinguer deux comptes (je dirais presque : "au contraire").

affichés à l'usager

Mais on est en backoffice où tous les attributs sont affichés; pourquoi considérer ce qui serait affiché à l'usager ?

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

affichés à l'usager

Mais on est en backoffice où tous les attributs sont affichés; pourquoi considérer ce qui serait affiché à l'usager ?

Parce que je parlais de l'API, mais oui, considérons que même elle sera toujours utilisée en backoffice, alors go go go : tous les attributs.

Valentin Deniaud a écrit :

Re une itération en montrant les attributs searchable=True, donc.

Je vais être pénible mais on avait dit "tous les attributs" :)

Je n'avais pas vu le champs caché « <input type="hidden" name="confirm-creation-token" ...> ». Si je comprends bien si on clique une seconde fois sur le bouton de validation, ça va ajouter l'utilisateur tant pis pour les doublons. Je préférerais quelque chose de plus explicite, soit changer le titre du bouton en "Créer quand même" soit (ma préférence) avoir une case à cocher « [ ] Créer ce nouvel utilisateur, ce n'est pas un doublon »