Produits Entr'ouvert » Authentic 2

Le modèle concernant les attributs des rôles est lui bien dans authentic, je pense qu'il serait temps que ça revienne entièrement dans authentic et de manière plus propre (à mon avis un stockage json dans le modèle du rôle directement serait plus approprié) mais je n'en ferai pas un pré-requis pour ce ticket.

Ça me va d'avoir un code tout bête dans a2 qui gère de base slug/name/ou__slug/ou__name et d'y aggréger un support ad-hoc de details, emails et emails_to_members quand on détecte que hobo.agent.authentic est chargé. Quand on saura faire plus propre on migrera. Comme pour les imports JSON il faudrait prévoir une affectation par défaut à l'OU par défaut, vraisemblablement avec une checkbox dans le formulaire d'import (ou un sélecteur, [ne rien faire, importer les rôles sans OU dans l'ou par défaut, importer les rôles sans OU dans l'ou XYZ, etc...].

Le fichier CSV minimal contiendrait juste des noms de rôles.

0001: ça fait beaucoup de changements juste pour hériter d'un seul champ, non ?
0002: il faudrait plutôt accumuler les ValidationError dans une liste errors et renvoyer tout ça à la fin, c'est un peu casse pied d'avoir les erreurs au compte-goutte; il faudrait valider que la ligne d'entête matche un modèle name,slug ou name,slug,ou ; la traduction des entête j'ai l'impression que ça complexifie pour rien, je trouve plus utile de valider que les colonnes sont biens celles qu'on attend.
0003: pas besoin si on vire 0001

Valentin Deniaud a écrit :

Je ne me suis pas engagé là dedans, je suis plutôt pour migrer et ensuite étendre ici (et par rapport à ce que tu écris, pourquoi stoker les attributs en json et pas en faire des champs de modèle normaux ? Il faudrait ouvrir un ticket qui en parle).

Le risque c'est que ça casse authentic ailleurs que dans Publik, le json ça laisse un signal que ça ne fait pas vraiment partie du modèle de donnée. Mon objectif c'est de remplacer le formulaires qui est dans hobo et surcharge le formulaire d'authentic par juste un peu de conf spécifique à publik configuration genre.

ROLE_ATTRIBUTES = [
  {
     'name': 'emails',
     'label': 'Courriels',
     'kind': 'emaillist',
  },
  etc...
]

et qu'on retrouve ces attributs dans l'API des rôles; chose qu'on a pas actuellement aussi. Et oui c'est pour un prochain ticket.

Benjamin Dauvergne a écrit :

0001: ça fait beaucoup de changements juste pour hériter d'un seul champ, non ?

C'est pour hériter de RolesImportForm, qui est plus qu'un seul champ, mais ça me pose pas de problème de dupliquer.

0002: il faudrait plutôt accumuler les ValidationError dans une liste errors et renvoyer tout ça à la fin, c'est un peu casse pied d'avoir les erreurs au compte-goutte

OK je vais faire ça.

il faudrait valider que la ligne d'entête matche un modèle name,slug ou name,slug,ou

OK mais pour le moment l'entête est carrément optionnel, je trouvais ça sympa.

la traduction des entête j'ai l'impression que ça complexifie pour rien

Oui ça dans le cadre authentic c'est pas top (j'ai pour l'instant copié le fonctionnement de l'import CSV des évènements dans chrono).

0003: pas besoin si on vire 0001

C'est quand même un bug, mais il aura son ticket du coup.

Valentin Deniaud a écrit :

il faudrait valider que la ligne d'entête matche un modèle name,slug ou name,slug,ou

OK mais pour le moment l'entête est carrément optionnel, je trouvais ça sympa.

C'est casse gueule, en tout cas on ne fait ça ni dans l'import des utilisateurs ni dans celui des fiches coté w.c.s., mais c'est vrai qu'on le fait par défaut dans csvdatasource. À mon avis c'est une mauvaise idée on gagne aucun temps à ne pas avoir d'entête, surtout si on fournit un exemple, et on en gagne quand le fichier est n'importe quoi.

la traduction des entête j'ai l'impression que ça complexifie pour rien

Oui ça dans le cadre authentic c'est pas top (j'ai pour l'instant copié le fonctionnement de l'import CSV des évènements dans chrono).

Hmm je vois encore un nouvel exemple d'import CSV, j'ai raté celui là.

0003: pas besoin si on vire 0001

C'est quand même un bug, mais il aura son ticket du coup.

Ok.

Valentin Deniaud a écrit :

Revoici, remarques appliquées sauf pour l'entête : des contrôles là dessus auraient du sens surtout pour permettre d'inverser l'ordre des colonnes etc, ce qui ne sera pas le cas ici.

J'insiste pour l'entête, qu'il soit fixe si tu veux :

if row != ['name', 'slug', 'ou'][:len(row)]:
   raise ValidationError(...)

Et aussi je ne comprends pas le .strip('#').