Project

General

Profile

Project management #8006

Supprimer la création de rôles dans w.c.s.

Added by Pierre Cros about 7 years ago. Updated over 6 years ago.

Status:
Fermé
Priority:
Haut
Category:
-
Target version:
-
Start date:
03 August 2015
Due date:
05 January 2016
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
Club:

Description

Et donc l'autoriser dans Authentic. 2 choses :
  • Ajouter un champ courriel aux rôles
  • Faire la synchronisation immédiatement

Related issues

Related to Hobo - Development #8217: Ajouter une tâche hobo pour notifier les agents des nouveaux rôles, connecter cette tâche aux signaux post_save, post_delete sur les rôlesFermé09 September 2015

Actions
Related to w.c.s. - Development #8219: nouvelle command 'notify' pour traiter les notifications provisionnement/déprovisionnement des rôles en provenance d'authenticFermé09 September 2015

Actions
Related to Authentic 2 - Bug #8234: webservice to add/remove users to/from rolesFermé10 September 201522 November 2015

Actions
Related to w.c.s. - Development #9210: Quand l'idp contrôle les rôles les actions de workflow pour ajouter/soustraire un rôle doivent utiliser le web-service de l'IdPFermé04 December 201530 December 2015

Actions
Related to Authentic 2 - Development #9806: Add PublikAuthentication to django-rest-framework authentication classes in the multitenant packageFermé29 January 2016

Actions

History

#1

Updated by Benjamin Dauvergne about 7 years ago

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à.

#2

Updated by Frédéric Péters (de retour le 10/10) about 7 years ago

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).

#3

Updated by Benjamin Dauvergne about 7 years ago

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.

En dehors de celle la j'ai plusieurs pistes:
  • 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.

#4

Updated by Frédéric Péters (de retour le 10/10) about 7 years ago

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
#5

Updated by Benjamin Dauvergne about 7 years ago

Bof.

#6

Updated by Frédéric Péters (de retour le 10/10) about 7 years ago

  • Priority changed from Normal to Haut
#7

Updated by Benjamin Dauvergne about 7 years ago

  • Related to Development #8217: Ajouter une tâche hobo pour notifier les agents des nouveaux rôles, connecter cette tâche aux signaux post_save, post_delete sur les rôles added
#8

Updated by Benjamin Dauvergne about 7 years ago

  • Related to Development #8219: nouvelle command 'notify' pour traiter les notifications provisionnement/déprovisionnement des rôles en provenance d'authentic added
#9

Updated by Frédéric Péters (de retour le 10/10) about 7 years ago

  • Related to Bug #8234: webservice to add/remove users to/from roles added
#10

Updated by Benjamin Dauvergne almost 7 years ago

  • Status changed from Nouveau to Solution déployée

C'est en prod pour meaux, ça arrive pour 3M.

#11

Updated by Pierre Cros almost 7 years ago

  • Status changed from Solution déployée to Fermé
#12

Updated by Pierre Cros almost 7 years ago

  • Status changed from Fermé to En cours
#13

Updated by Pierre Cros almost 7 years ago

  • Due date changed from 15 September 2015 to 27 November 2015
#14

Updated by Benjamin Dauvergne almost 7 years ago

  • Due date changed from 27 November 2015 to 02 December 2015
#15

Updated by Benjamin Dauvergne almost 7 years ago

  • Related to Development #9210: Quand l'idp contrôle les rôles les actions de workflow pour ajouter/soustraire un rôle doivent utiliser le web-service de l'IdP added
#16

Updated by Benjamin Dauvergne over 6 years ago

  • Due date changed from 02 December 2015 to 05 January 2016
#17

Updated by Benjamin Dauvergne over 6 years ago

  • Related to Development #9806: Add PublikAuthentication to django-rest-framework authentication classes in the multitenant package added
#18

Updated by Benjamin Dauvergne over 6 years ago

  • Status changed from En cours to Solution déployée

Also available in: Atom PDF