Produits Entr'ouvert » Hobo

Ok je met ça sur le haut de la pile.

Ce n'est pas entièrement fini, il me reste à voir comment adapter la command sync-ldap-users pour qu'elle fonctionne avec ça, je pense ajouter des hooks et surcharger la commande dans l'application hobo.agent.authentic2.

À noter que ça change le fonctionnement du provisionning des rôles, avant on envoyait systématiquement tous les rôles à chaque création d'un rôle (full=True dans les messages). Maintenant on les envoie un par un, c'est un peu plus léger. Mais j'envisage d'ajouter une commande "provision-roles" au cas où.

Le fichier provisionning.py est absent du patch.

Benjamin Dauvergne a écrit :

Mais j'envisage d'ajouter une commande "provision-roles" au cas où.

Oui, ça sera bien utile, pour ne pas dire nécessaire, lors de l'initialisation d'une plateforme

D'abord un échec parce que le process_response ne renvoyait pas de réponse (corrigé en ajoutant un "return response" dedans) (je suis en django 1.8).

Ensuite, sur la modif d'un attribut de mon compte :

[2016-09-23 Fri 09:32:01] - - - ERROR hobo.agent.authentic2.provisionning.do_provision: error in provisionning thread
Traceback (most recent call last):
  File "/home/fred/src/eo/hobo/hobo/agent/authentic2/provisionning.py", line 201, in do_provision
    self.notify_users(ous, saved.get(self.User, []))
  File "/home/fred/src/eo/hobo/hobo/agent/authentic2/provisionning.py", line 102, in notify_users
    for service, audience in self.get_audience(user):
  File "/home/fred/src/eo/hobo/hobo/agent/authentic2/provisionning.py", line 225, in get_audience
    qs = LibertyProvider.objects.filter(ou=ou)
  File "/home/fred/src/eo/venv/local/lib/python2.7/site-packages/django/db/models/manager.py", line 127, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/home/fred/src/eo/venv/local/lib/python2.7/site-packages/django/db/models/query.py", line 679, in filter
    return self._filter_or_exclude(False, *args, **kwargs)
  File "/home/fred/src/eo/venv/local/lib/python2.7/site-packages/django/db/models/query.py", line 697, in _filter_or_exclude
    clone.query.add_q(Q(*args, **kwargs))
  File "/home/fred/src/eo/venv/local/lib/python2.7/site-packages/django/db/models/sql/query.py", line 1310, in add_q
    clause, require_inner = self._add_q(where_part, self.used_aliases)
  File "/home/fred/src/eo/venv/local/lib/python2.7/site-packages/django/db/models/sql/query.py", line 1338, in _add_q
    allow_joins=allow_joins, split_subq=split_subq,
  File "/home/fred/src/eo/venv/local/lib/python2.7/site-packages/django/db/models/sql/query.py", line 1179, in build_filter
    self.check_related_objects(field, value, opts)
  File "/home/fred/src/eo/venv/local/lib/python2.7/site-packages/django/db/models/sql/query.py", line 1074, in check_related_objects
    self.check_query_object_type(value, opts)
  File "/home/fred/src/eo/venv/local/lib/python2.7/site-packages/django/db/models/sql/query.py", line 1058, in check_query_object_type
    (value, opts.object_name))
ValueError: Cannot query "fred (fred)": Must be "OrganizationalUnit" instance.

J'ai un patch mais j'essaie de voir pourquoi les tests passent quand même d'abord.

Et donc ça passe parce que pour Django 1.7 tout ce qui a un champ .pk ou .id est un modèle, il ne regarde pas le type dans les filtres, et les tests Django 1.8 ne marchait pas parce qu'hobo a encore une contrainte < 1.8. Est-ce que quelqu'un voit un inconvénient à ce que je relâche cette contrainte pour autoriser hobo et Django 1.8 ?

Je tourne en hobo et django 1.8 depuis longtemps. (et montpellier aussi sur de la prod). Pas de problème pour moi donc.

(correction, j'étais resté sur l'idée que jessie était en 1.8 mais non, donc à part en local on n'a pas de 1.8 qui tourne vraiment toutes les briques)

Le message est encore envoyé une fois par "audience"; le provisionning des utilisateurs pourrait avoir lieu comme celui des rôles, où audience reprend la liste des services ?

J'ai un souci pour l'attribut is_superuser qui est spécifique au service et j'ai choisi la facilité.

Ce que je peux faire c'est vérifier si l'utilisateur a un is_superuser, si ce n'est pas le cas je le provisionne en une fois vers toutes les audiences, sinon j'utilise la méthode actuellee. Ça ira vite pour les usagers et plus lentement pour les agents, ok ?

Yep, surtout que les agents is_superuser, ça ne doit même pas être la majorité.

Le commentaire dans le patch,

1. Find roles giving a superuser attribute
2. Split users between those with these roles and those without

Est trompeur; comme tu l'écris dans le ticket, ça fait "qu'ils n'ont pas d'attribut de rôle", pas le côté "superuser". Et du coup, dès qu'un usager a un rôle, et c'est fréquent (genre Alfortville les usagers ont un rôle "Parent"), on bascule sur le mode lent.

Pourquoi ne pas faire le filtre sur attribute__name="is_superuser" / __value="true", pour correspondre au code qui sera effectif plus loin :

                        for attribute in role.attributes.all():
                            if attribute.name == 'is_superuser' and attribute.value == 'true':
                                role_is_superuser = True

?

Voilà, je l'ai un petit peu utilisé en local, pour moi c'est ok à pousser.