Bug #31130
sur un publik, les rôles de base ont le même slug "_a2-hobo-superuser"
0%
Description
Sur un Publik déployé, on voit que les rôles "administrateur de xxx" ont tous le même slug "_a2-hobo-superuser" :
"roles": [
{
"description": "",
"service": {
"ou": {
"slug": "default",
"uuid": "f21588fb3ea7458d9a97c561e3ea9a91",
"name": "Ville d'Avray"
},
"slug": "hobo"
},
"name": "Administrateur de Hobo",
"attributes": [
{
"kind": "string",
"name": "is_superuser",
"value": "true"
}
],
"ou": {
"slug": "default",
"uuid": "f21588fb3ea7458d9a97c561e3ea9a91",
"name": "Ville d'Avray"
},
"external_id": "",
"slug": "_a2-hobo-superuser",
"uuid": "e70d086e877d457b81b867987aa39b28"
},
{
"description": "",
"service": {
"ou": {
"slug": "default",
"uuid": "f21588fb3ea7458d9a97c561e3ea9a91",
"name": "Ville d'Avray"
},
"slug": "portal"
},
"name": "Administrateur de Portail",
"attributes": [
{
"kind": "string",
"name": "is_superuser",
"value": "true"
}
],
"ou": {
"slug": "default",
"uuid": "f21588fb3ea7458d9a97c561e3ea9a91",
"name": "Ville d'Avray"
},
"external_id": "",
"slug": "_a2-hobo-superuser",
"uuid": "2fd417b471d3457891a6862dbb8b1ddc"
},
{
"description": "",
"service": {
"ou": {
"slug": "default",
"uuid": "f21588fb3ea7458d9a97c561e3ea9a91",
"name": "Ville d'Avray"
},
"slug": "portal-agent"
},
"name": "Administrateur de Portail Agent",
"attributes": [
{
"kind": "string",
"name": "is_superuser",
"value": "true"
}
],
"ou": {
"slug": "default",
"uuid": "f21588fb3ea7458d9a97c561e3ea9a91",
"name": "Ville d'Avray"
},
"external_id": "",
"slug": "_a2-hobo-superuser",
"uuid": "a0335ae33b5c4d3aaa5540cdaa9b6a62"
},
...
A priori pas de problème technique parce que chacun de ces rôles est lié à son service, mais le fait que le slug soit "hobo-superuser" et non pas "<slug-du-service>-superuser", je me demande si y'a un trou quelque part
Demandes liées
Historique
Mis à jour par Thomas Noël il y a environ 5 ans
- Projet changé de Authentic 2 à Hobo
C'est dans hobo que c'est géré, de fait.
Mis à jour par Thomas Noël il y a environ 5 ans
dans hobo/agent/authentic2/management/commands/hobo_deploy.py :
176 name = _('Superuser of %s') % service['title']
177 su_role, created = Role.objects.get_or_create(
178 service=provider, slug='_a2-hobo-superuser',
179 defaults={'name': name})
On pourrait presque imaginer ici prendre '_a2-%s-superuser' % service['slug'] ?
Mais peut-être que je me trompe que ce nom "a2-hobo-superuser" a une raison d'être.
Mis à jour par Thomas Noël il y a environ 5 ans
- Priorité changé de Normal à Bas
Priorité basse parce que je pense que c'est pas vraiment totalement un bogue (ça fait rien planter, juste mes yeux).
Mis à jour par Benjamin Dauvergne il y a environ 5 ans
Thomas Noël a écrit :
dans hobo/agent/authentic2/management/commands/hobo_deploy.py :
[...]
On pourrait presque imaginer ici prendre '_a2-%s-superuser' % service['slug'] ?
Mais peut-être que je me trompe que ce nom "a2-hobo-superuser" a une raison d'être.
J'ai fait comme cela par flemme je pense, il faut juste regarder si rien ne dépend de ce nommage quelque part avant de changer, mais comme il y a hobo dedans je ne pense pas, ça pourrait facilement devenir '_a2-service-<x>-admin', juste vérifier la taille max de slug et ne pas dépasser.
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Lié à Bug #57150: publik multicollectivités : sur une collectivité, tous les slug des rôles "administrateurs de xxx" sont identiques "_a2_hobo_superuser" ajouté
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Priorité changé de Bas à Normal
- Planning mis à Non
Ça continue à surprendre.
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
Je peux comprendre mais pour la stabilité du provisionning de ce rôle ce serait vraiment problématique que son slug contienne quelque chose de variable, si jamais on change le nom ou le slug du service en question on se retrouverait avec deux rôles.
Il faudrait ajouter encore un champ de nommage aux rôles, une colonne "use", avec un index d'unicité partiel en fonction de la nullité de service ou pas (ce qui est fait aussi sur name et slug). On pourrait ensuite y mettre 'service-superuser-role' et ainsi laisser le slug libre s'il faut vraiment que cet identifiant technique ait un nom avec une signification évidente. Au départ cette signification était sensé venir du triplet (ou, service, slug/name)
Mis à jour par Frédéric Péters il y a plus de 2 ans
Faut compter de toute façon que tout s'écroule si on change le slug d'un service; ça n'est heureusement pas quelque chose de possible via l'UI.