Produits Entr'ouvert » Publik

• seuls champs obligatoires : mail, nom et prénom
• bémol sur la date de naissance (c'est à mon avis inutile dans 99% des demandes, et c'est une donnée plutôt personnelle)

Le blocage du profil dans wcs me semblait déjà fait ? (quand c'est l'IdP qui est déclaré contrôler les attributs, c'est déjà ainsi, non ?)

On vise un plus petit dénominateur ou un plus grand multiple commun ?

Pour ce ticket il faudra ajouter à la commande check-hobos le fait de définir un mapping des attributs via attribute-mapping (si le config.pck n'en contient pas encore, pour éviter d'écraser la configuration). Je lie un ticket sur w.c.s. pour cela.

Ok pour moi concernant les champs retenus.

Côté configuration authentic, le premier écran d'activation du compte, on mettrait uniquement prénom et nom, obligatoires, par défaut ?

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

Côté configuration authentic, le premier écran d'activation du compte, on mettrait uniquement prénom et nom, obligatoires, par défaut ?

Moi je mettrais tous les champs, mais en premier et clairement "les seuls qui soient obligatoires" (nom et prénom). J'ai en revanche pas d'idée sur le "clairement"... (des champs un peu estompés pour les autres, ou avec des bords gris, que sais-je...)

À regarder la config Montpellier,

A2_ATTRIBUTE_KINDS = [
        {
            'label': u'Civilité',
            'name': 'title',
            'field_class': forms.ChoiceField,
            'kwargs': {
                'choices': [
                    ('', u'Choisissez une valeur'),
                    ('monsieur', u'Monsieur'),
                    ('madame', u'Madame'),
                ],
            }
         },
 ]

A2_REGISTRATION_FIELDS = ('civilite', 'first_name', 'last_name', 'address', 'zipcode', 'city', 'birthdate', 'phone', 'mobile')
A2_REGISTRATION_REQUIRED_FIELDS = ('first_name', 'last_name')

+ modif à l'agent authentic hobo pour partager ces attributs; d'autres choses ?

Il faut simplement initialiser les modèles authentic.models.Attribute correspondant dans l'agent authentic, il faut aussi poser au niveau des settings les bonnes valeurs pour A2_PROFILE_FIELDS , A2_REQUIRED_FIELDS et A2_REGISTRATION_FIELDS respectivement les champs éditables via la page de profil, les champs requis, les champs demandé à l'enregistrement, le deuxième est forcément inclus dans le deuxième. À noter que que ces settings ne concernent vraiment que les champs encore portés par l'objet User, le comportement des autres champs est géré via le modèle Attribute, à part leur ordre.

C'est traité de cette manière:

        attributes = models.Attribute.objects.filter(
                asked_on_registration=True)
        default_fields = attributes.values_list('name', flat=True)
        fields, labels = get_fields_and_labels(
            app_settings.A2_REGISTRATION_FIELDS,
            default_fields,
            app_settings.A2_REGISTRATION_REQUIRED_FIELDS,
            app_settings.A2_REQUIRED_FIELDS,
            models.Attribute.objects.filter(required=True).values_list('name', flat=True))

(Un peu complexe mais il fallait maintenir l'existant)

Les champs apparaissent dans l'ordre où ils sont trouvés la première fois dans toutes ces listes, ces listes peuvent être simplement le nom des champs, ou le nom du champ et une surcharge du label.

À noter que les labels des champs définis via Attribute ne sont pas traduisibles, pour IMIO ça peut être un problème ?

À noter que que ces settings ne concernent vraiment que les champs encore portés par l'objet User.

Si les variables dans le settings, elles s'appliquent uniquement à prénom/nom/email (les champs que je vois dans custom_user/models.py), pourquoi les autres s'y trouvent mentionnés dans la config de Montpellier, c'est un reste de vieille config ou je passe à côté d'un truc ?

Les champs apparaissent dans l'ordre où ils sont trouvés la première fois dans toutes ces listes [...]

Mais donc ici on met dans les listes tous les attributs, ce qui me semble correspondre à Montpellier; mais alors je ne comprends pas la remarque précédente ("... ne convernent vraiment que...").

À noter que les labels des champs définis via Attribute ne sont pas traduisibles, pour IMIO ça peut être un problème ?

Ça sera un problème, oui, mais les premières villes ne sont pas bilingues.

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

À noter que que ces settings ne concernent vraiment que les champs encore portés par l'objet User.

Si les variables dans le settings, elles s'appliquent uniquement à prénom/nom/email (les champs que je vois dans custom_user/models.py), pourquoi les autres s'y trouvent mentionnés dans la config de Montpellier, c'est un reste de vieille config ou je passe à côté d'un truc ?

Parce que comme je le dis ça permet aussi de contrôler l'ordre ce qu'on ne peut pas faire via le modèle Attribute, même en ajoutant un champ order on aurait pas les champs legacy dans le tas. Je n'ai pas de solution à ce problème pour l'instant, il faudrait peut-être avoir des pseudos-instance de Attribute qu'on ne puisse pas ni effacer ni renommer pour supprimer le besoin des variables de settings. En attendant on a besoin des deux.

Les champs apparaissent dans l'ordre où ils sont trouvés la première fois dans toutes ces listes [...]

Mais donc ici on met dans les listes tous les attributs, ce qui me semble correspondre à Montpellier; mais alors je ne comprends pas la remarque précédente ("... ne convernent vraiment que...").

Elle est imprécise oui.

À noter que les labels des champs définis via Attribute ne sont pas traduisibles, pour IMIO ça peut être un problème ?

Ça sera un problème, oui, mais les premières villes ne sont pas bilingues.

Ok. C'est vrai pour tout ce qui sort des modèles en générale (noms des rôles, noms de services, etc...). Il faudra peut-être utiliser une des librairies django qui permet de traduire les champs textes des modèles à un moment.

Le jeudi 07 mai 2015 à 14:18 +0200, redmine@entrouvert.com a écrit :

ça voudrait peut-être dire aussi qu'on bloquerait l'édition du profil
dans wcs

Oui, il ne peut pas y avoir deux endroits où on édite le profil et donc
c'est sur Authentic que ça se passe (mais j'ai peut-être mal compris).

… qu'on bloquerait l'édition du profil dans wcs (?)

Imprécis, je parlais là du paramétrage du profil.

IMIO demande, en contradiction avec une demande précédente, les champs
suivants dans le profil :

Nom*
Prénom*
Numéro national
Numéro de carte d'identité*
Rue & numéro*
Code Postal & localité*
Courriel*
Numéro de téléphone*
Numéro de téléphone

Pour les gens qui ne se connectent pas via la carte d'identité (peut-être n'est-ce pas possible...) le numéro de carte d'identité je le prends juste en déclaratif ?

Il ne doit pour le moment pas y avoir d'action entreprise par rapport à ces derniers changements Imio.