Produits Entr'ouvert » Publik

Je me dis que le mail pourrait passer simplement par une convention du genre avoir une ligne email: role@clapiers.fr dans la description.

Concernant la synchronisation le plus simple me semblerait de passer par une notification d'authentic à hobo "un truc a bougé", et hobo réveillerait tous les agents. À charge pour chaque agent de venir lire la liste des rôles dans authentic.

Un problème non évoqué ici est l'utilisation de rôles non attachés à un service comme rôles applicatifs (rôles répliqués dans w.c.s.). Il faudrait pour cela transmettre le slug des rôles de l'utilisateur restreints à la collectivité du service, on pourrait appeler ce nouvel attribute "identifiants courts des rôles dans la collectivité de l'application". On utiliserait l'attribut "role-slug" qu'on utilise déjà.

Benjamin Dauvergne a écrit :

Je me dis que le mail pourrait passer simplement par une convention du genre avoir une ligne email: role@clapiers.fr dans la description.

Vraiment pas enthousiaste.

Concernant la synchronisation le plus simple me semblerait de passer par une notification d'authentic à hobo "un truc a bougé", et hobo réveillerait tous les agents. À charge pour chaque agent de venir lire la liste des rôles dans authentic.

Je ne suis pas sûr qu'on ait eu le temps de l'écrire mais avec Thomas on était arrivé sur un fonctionnement similaire, avec option sur une variante (notif d'authentic à hobo, de hobo à authentic récup d'infos supplémentaires, notif d'hobo aux agents, qui n'auraient ainsi pas à causer à authentic) (dans notre cas on parlait plutôt de passerelle que d'authentic). (mais l'idée principale, hobo comme hub, est celle qui est importante).

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

Benjamin Dauvergne a écrit :

Je me dis que le mail pourrait passer simplement par une convention du genre avoir une ligne email: role@clapiers.fr dans la description.

Vraiment pas enthousiaste.

• ajouter un champ email en dur mais ça m'embête parce que c'est encore une fonctionnalité pour un cas particulier qui n'a pas vraiment d'intérêt en général (c'est le moins de taf)
• réutiliser le système des attributs attachés aux rôles et l'exposer dans le manager pour tous les rôles "éditables", il faudra définir un attribut nommé email avec la valeur voulue (c'est un taf moyen), le truc c'est que ce n'est pas super "ergonomique" dans le sens où ça ne propose pas directement de remplir un champ nommé "Email", on pourrait prévoir une liste de choix possibles plutôt qu'un champ libre.
• avoir un système de champs génériques comme pour les utilisateurs en essayant peut-être de partager l'implémentation existante (ça représente beaucoup et si on a juste un champ là tout de suite maintenant, un peu inutile)

Concernant la synchronisation le plus simple me semblerait de passer par une notification d'authentic à hobo "un truc a bougé", et hobo réveillerait tous les agents. À charge pour chaque agent de venir lire la liste des rôles dans authentic.

Je ne suis pas sûr qu'on ait eu le temps de l'écrire mais avec Thomas on était arrivé sur un fonctionnement similaire, avec option sur une variante (notif d'authentic à hobo, de hobo à authentic récup d'infos supplémentaires, notif d'hobo aux agents, qui n'auraient ainsi pas à causer à authentic) (dans notre cas on parlait plutôt de passerelle que d'authentic). (mais l'idée principale, hobo comme hub, est celle qui est importante).

On peut implémenter une sorte d'amqp over http, un endroit où on peut poster des données JSON avec une clé de routage et un autre endroit où on peut enregistrer une URL où ces mêmes données devront être repostés selon une regexp sur les clés de routage; le tout avec une queue persistante aux fesses si jamais le re-POST ne marche pas.

Benjamin Dauvergne a écrit :

On peut implémenter une sorte d'amqp over http, un endroit où on peut poster des données JSON avec une clé de routage et un autre endroit où on peut enregistrer une URL où ces mêmes données devront être repostés selon une regexp sur les clés de routage; le tout avec une queue persistante aux fesses si jamais le re-POST ne marche pas.

Je serais plutôt pour l'adoption simple de celery, comme on l'utilise déjà dans hobo.

• authentic → hobo, ping "new info"
• hobo → authentic, get "new info" (dictionnaire en réponse, sera utilisé pour construire les hobo.json)
• hobo → *, deploy

Bof.