Produits Entr'ouvert » w.c.s.

if action == 'provision':
    # Provision/rename
    role.name = name
    role.slug = uuid
    role.store()
elif action == 'provision': <-- 'deprovision' ?
    # Deprovision
    role.remove_self()

Taper dans une méthode séparée ce qui suit le notification = json.load..., histoire de faciliter la création de tests.

Ah j'ai du mal m'exprimer. Pour faciliter les tests mon idée c'est de réduire le execute(), qui ferait en gros

[...]
notification = self.load_notification(args)
if not self.check_valid_input(notification): sys.exit(1)
self.process_notification(notification)

Comme ça on peut avoir des tests sur le process_notification().

Cool; (ett → etat, dans le slug ? (j'ai d'abord cru que c'était partie intégrante du test d'avoir la lettre manquante)).

On n'a jamais de full=True, il me semble; tu imagines ce passage arriver quand ?

Le full=True est dans le dernier patch du ticket #8217 ou alors je n'ai pas attaché le bon. Le 'ett' est volontaire.

(je n'arrive pas à comprendre le sens de ett, pas grave).

Je vois le full: True; maintenant que c'est le cas de manière systématique, il pourrait juste ne pas exister ? Et/ou on le garde simplement par anticipation du moment où on voudra qu'il ne soit plus systématique ?

Je préfère garder les deux modes; je ne sais pas encore comment ça va se comporter à Montpellier particulièrement, je me laisse le choix de revenir sur des envois ponctuels et du full de temps en temps.

Un autre souci que je vois pour Montpellier c'est le cas de rôles pour Sussargues et pas pour Clapiers, qui n'est pas géŕé, tout les w.c.s. reçoivent tous les rôles.

Ah oui, ça va pas du tout aller :/

Quand des entités sont utilisées, il faudrait grouper par entité et mettre en "audience" uniquement les SP attachés à celle-ci ?

Yep je pense que c'est un peu ça: lors de la modification d'un rôle lié à une entité on balance tous les rôles de l'entité et tous les rôle sans entités aux SPs de cette entité, sauf les rôles d'administration (ceux qui ont un admin_scope non nul).

→ #8217 ce patch.

Il reste une mention du nom :

class CmdNotify(Command):
    name = 'notify'

et mini-truc, dans test_process_notification_wrong_audience, les deux rôles ont le même uuid (12345, lignes 38 et 44 de tests/test_hobo_notify.py)

en relisant je me dis que ça pourrait planter si un rôle n'existe pas alors qu'il doit être "déprovisionné".

• ajouter un role = None avant le try ligne 95 (Find existing role)
• et alors elif action == 'deprovision' and role: ligne 110

Il y a un if action != 'provision': continue pour ça ? Dans quel cas ça pourrait continuer ? L'exception KeyError ne serait pas levé et role serait quand même None ?

J'avais raté le "if action != 'provision':". Sorry.

Truc que j'avais raté, qui m'est revenu ce matin; dans wcs on a absolument besoin d'un attribut email aux rôles. (et en fait, dans wcs, c'est une liste d'emails, je vais vérifier si c'est utilisé avec plusieurs emails parfois, mais je pense que oui).

Concernant les autres attributs :

• details, pour contenir une description, pas indispensable immédiatement, mais tant qu'à ajouter email, autant prendre celui-là aussi ;
• emails_to_members, qui détermine si les mails sont également distribués aux adresses individuelles des membres; là-dessus je dirais que s'il n'y a pas d'emails du tout, ça doit être mis à True, et dans le cas contraire, ça ne doit pas être touché ;
• allows_backoffice_access, ne doit pas être touché mais nécessite l'ajout d'un nouveau panneau de paramétrage où pourront être sélectionnés les rôles ayant accès au backoffice. (la valeur par défaut c'est True, on ne la change pas, on verra plus tard). (je m'occupe de cette partie, #8239)

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

Truc que j'avais raté, qui m'est revenu ce matin; dans wcs on a absolument besoin d'un attribut email aux rôles. (et en fait, dans wcs, c'est une liste d'emails, je vais vérifier si c'est utilisé avec plusieurs emails parfois, mais je pense que oui).

Concernant les autres attributs :

• details, pour contenir une description, pas indispensable immédiatement, mais tant qu'à ajouter email, autant prendre celui-là aussi ;

Je pense que peux projeter le champ description du modèle Role là dessus sans trop de soucis, ça me semble être la même chose.

• emails_to_members, qui détermine si les mails sont également distribués aux adresses individuelles des membres; là-dessus je dirais que s'il n'y a pas d'emails du tout, ça doit être mis à True, et dans le cas contraire, ça ne doit pas être touché ;

• j'ai ajouté un setting pour surcharger la classe de formulaire utilisée dans le manager pour éditer la définition d'un rôle
• dans l'application hobo.agent spécifique à authentic2 je vais ajouter la définition d'une telle class qui sauvegardera la valeur de ces deux champs dans des modèles RoleAttribute
• dans le AppConfig de la même application je poserai le setting A2_MANAGER_ROLE_FORM_CLASS qu'il faut

• allows_backoffice_access, ne doit pas être touché mais nécessite l'ajout d'un nouveau panneau de paramétrage où pourront être sélectionnés les rôles ayant accès au backoffice. (la valeur par défaut c'est True, on ne la change pas, on verra plus tard). (je m'occupe de cette partie, #8239)

Ok.

Autre chose, pour ne pas perdre les données actuellement stockés dans les champs emails et emails_to_members il faudrait que les dernières exécutions de import-wcs-roles les recopient dans les modèles RoleAttribute, mais pour cela il faudrait qu'ils soient exportés par l'API /api/roles ce qui ne semble pas le cas -> #8254.

(comme #8254) Il manque la gestion de description→details.