Projet

Général

Profil

Project management #8006

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

Ajouté par Pierre Cros il y a plus de 8 ans. Mis à jour il y a environ 8 ans.

Statut:
Fermé
Priorité:
Haut
Assigné à:
Catégorie:
-
Version cible:
-
Début:
03 août 2015
Echéance:
05 janvier 2016
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Club:

Description

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

Demandes liées

Lié à 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 septembre 2015

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

Actions
Lié à Authentic 2 - Bug #8234: webservice to add/remove users to/from rolesFermé10 septembre 201522 novembre 2015

Actions
Lié à 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 décembre 201530 décembre 2015

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

Actions

Historique

#1

Mis à jour par Benjamin Dauvergne il y a plus de 8 ans

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

Mis à jour par Frédéric Péters il y a plus de 8 ans

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

Mis à jour par Benjamin Dauvergne il y a plus de 8 ans

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

Mis à jour par Frédéric Péters il y a plus de 8 ans

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

Mis à jour par Benjamin Dauvergne il y a plus de 8 ans

Bof.

#6

Mis à jour par Frédéric Péters il y a plus de 8 ans

  • Priorité changé de Normal à Haut
#7

Mis à jour par Benjamin Dauvergne il y a plus de 8 ans

  • Lié à 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 ajouté
#8

Mis à jour par Benjamin Dauvergne il y a plus de 8 ans

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

Mis à jour par Frédéric Péters il y a plus de 8 ans

  • Lié à Bug #8234: webservice to add/remove users to/from roles ajouté
#10

Mis à jour par Benjamin Dauvergne il y a plus de 8 ans

  • Statut changé de Nouveau à Solution déployée

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

#11

Mis à jour par Pierre Cros il y a plus de 8 ans

  • Statut changé de Solution déployée à Fermé
#12

Mis à jour par Pierre Cros il y a plus de 8 ans

  • Statut changé de Fermé à En cours
#13

Mis à jour par Pierre Cros il y a plus de 8 ans

  • Echéance changé de 15 septembre 2015 à 27 novembre 2015
#14

Mis à jour par Benjamin Dauvergne il y a plus de 8 ans

  • Echéance changé de 27 novembre 2015 à 02 décembre 2015
#15

Mis à jour par Benjamin Dauvergne il y a plus de 8 ans

  • Lié à 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 ajouté
#16

Mis à jour par Benjamin Dauvergne il y a environ 8 ans

  • Echéance changé de 02 décembre 2015 à 05 janvier 2016
#17

Mis à jour par Benjamin Dauvergne il y a environ 8 ans

  • Lié à Development #9806: Add PublikAuthentication to django-rest-framework authentication classes in the multitenant package ajouté
#18

Mis à jour par Benjamin Dauvergne il y a environ 8 ans

  • Statut changé de En cours à Solution déployée

Formats disponibles : Atom PDF