-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Permissions : Création de groupes pour l'administration de GPS et Pilotage #5309
Conversation
00dbe84
to
aa208be
Compare
aa208be
to
3e13ecd
Compare
gps_models.FollowUpGroup: PERMS_ALL, | ||
gps_models.FollowUpGroupMembership: PERMS_ALL, | ||
users_models.User: PERMS_ADD | PERMS_HIJACK, | ||
users_models.JobSeekerProfile: PERMS_EDIT, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pourquoi permettre à GPS de mettre à jour les informations de profil ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Car je me suis dit que si GPS a besoin d'ajouter des bénéficiaires donc des comptes candidats alors la modification du profil était aussi nécessaire, c'est quelque chose qui a été demandé la semaine dernière par Camille car LJ est en congés et vu qu'il est dans itou-admin
bah il a toujours pû 😅.
C'est pour ça que j'ai mis la team GPS pour la relecture, car je sais pas du tout ce qui est OK ou pas 😏.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Je comprends mieux.
L'idée me met plutôt mal à l'aise car on risque de se retrouver avec des utilisateurs des emplois qui n'ont rien à voir avec le service. Nos règles de gestion peuvent aussi évoluer sans que GPS ne soit au courant. Il y a un risque de données incohérentes. Bon, après, le risque est faible car les cas concernés seront marginaux.
Pour garder une trace des User et UserProfile créés par GPS, je propose que le created_by
soit renseigné automatiquement en indiquant le compte de Louis-Jean ou de Camille. Qu'en penses-tu ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Traité pour User()
dans cette PR : #5321
Pour les jobSeekerProfile()
ce n'est pas nécessaire car leur création est lié à la création d'un User()
quand celui-ci est un candidat, il n'y a d'ailleurs pas de champs created_by
sur le modèle, et de toute façon les permissions n'autorisent justement pas la création de ce type d'objet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Merci !
@@ -283,6 +283,7 @@ class Meta(AbstractUser.Meta): | |||
), | |||
), | |||
] | |||
permissions = [("hijack_user", "Can impersonate (hijack) other accounts")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellente idée ! Je suppose donc qu'une autre PR viendra mettre à jour la permission des utilisateurs concernés puis supprimer HIJACK_ALLOWED_USER_EMAILS
de itou-secrets
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
La mise à jour des permissions ne sera pas faite dans une PR pour ne pas faire fuiter les emails mais effectivement une PR suivra pour supprimer HIJACK_ALLOWED_USER_EMAILS
sauf si quelqu'un trouve un cas qui demanderais de garder cette liste blanche plutôt que d'utiliser la permission Django.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👌 Si le cas existe, en tous cas, il ne me saute pas aux yeux.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
itou/utils/perms/user.py
Outdated
@@ -20,7 +20,9 @@ def has_hijack_perm(*, hijacker, hijacked): | |||
return True | |||
|
|||
# Only whitelisted staff members can hijack other accounts | |||
if hijacker.is_staff and hijacker.email.lower() in settings.HIJACK_ALLOWED_USER_EMAILS: | |||
if hijacker.is_staff and ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Je pense que tu aurais pu directement retirer le settings, et ajouter la permission dans la foulée.
La probabilité que tu gènes quelqu'un pendant ces quelques minutes est faible, non ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Je l'ai pas tant fait pour gêner ou pas que j'avais un doute de si on pouvais encore avoir besoin du settings, et vu que j'accumule les PR ouvertes je voulais pas en "bloquer" une avec une action synchrone, mais je vais rajouter le commit et la passer cette semaine vu que j'ai eu des tampons ;)
Also extract into its own test file instead of the generic one.
3e13ecd
to
2257bf6
Compare
🤔 Pourquoi ?
Idées directrices (long terme)
Besoin immédiat
Ne pas avoir de droits personnels sans donner accès à tout le reste via le groupe
itou-admin
Simplifier la gestion manuelle de
HIJACK_ALLOWED_USER_EMAILS
qui au final contient les emails des personnes concernés par ces 2 groupes