Il est nécessaire de pouvoir cacher certaines informations personnelles concernant un membre à toute personne n'ayant pas une telle autorisation.
L'idée c'est de réserver au bureau l'accès à ces données pour protéger la vie privée des membres de l'association.
Par exemple dans la fiche Membres,
Un trésorier a besoin de la partie cotisation (cette vue est très pratique pour voir toutes les cotisations d'un membre donné), date d'adhésion, nom d'usage,...
Par contre l'accès à l'adresse, nom, prénom, n'est pas forcément nécessaire.
Il est nécessaire de pouvoir cacher certaines informations personnelles concernant un membre à toute personne n'ayant pas une telle autorisation.
L'idée c'est de réserver au bureau l'accès à ces données pour protéger la vie privée des membres de l'association.
Par exemple dans la fiche Membres,
Un trésorier a besoin de la partie cotisation (cette vue est très pratique pour voir toutes les cotisations d'un membre donné), date d'adhésion, nom d'usage,...
Par contre l'accès à l'adresse, nom, prénom, n'est pas forcément nécessaire.
https://www.illyse.org/issues/199
Mis à jour par Baptiste Jonglez il y a plus d'un an
C'est une bonne idée, mais ça demande un peu de boulot.
Notamment parce qu'on ne gère pas plusieurs groupes avec des droits d'accès différents. Qui aurait le privilège d'éditer ces droits, pour pouvoir attribuer des gens aux différents rôles et droits ? (adminsys, membre du bureau, trésorier, etc)
> Mis à jour par Baptiste Jonglez il y a plus d'un an
> C'est une bonne idée, mais ça demande un peu de boulot.
> Notamment parce qu'on ne gère pas plusieurs groupes avec des droits d'accès différents. Qui aurait le privilège d'éditer ces droits, pour pouvoir attribuer des gens aux différents rôles et droits ? (adminsys, membre du bureau, trésorier, etc)
Mis à jour par Baptiste Jonglez il y a plus d'un an
Notes de la réunion du 28/06 concernant les droits d'accès aux données :
Membre simple : uniquement accès à ses propres données (cf. #202)
Membre du bureau : accès à toutes les données (super-user)
"Gestionnaire technique" :
peut accéder aux informations administrative des abonnements d'un membre (mais pas à l'objet membre lui-même)
peut accéder à la configuration technique des services d'un membre
C'est trop compliqué de gérer des permissions plus fines au sein du bureau (factures, données personnelles, etc). En revanche, il y a quelques mesures simples qui peuvent éviter certains abus :
Notifications par mail lorsqu'une personne change de groupe (notifier le bureau, ou carrément notifier les gens qui sont déjà dans le groupe, utile par exemple pour un groupe adminsys)
Empêcher de modifier ses propres groupes ?
> Mis à jour par Baptiste Jonglez il y a plus d'un an
> Notes de la réunion du 28/06 concernant les droits d'accès aux données :
> * Membre simple : uniquement accès à ses propres données (cf. #202)
> * Membre du bureau : accès à toutes les données (super-user)
> * "Gestionnaire technique" :
> * peut accéder aux informations administrative des abonnements d'un membre (mais pas à l'objet membre lui-même)
> * peut accéder à la configuration technique des services d'un membre
> C'est trop compliqué de gérer des permissions plus fines au sein du bureau (factures, données personnelles, etc). En revanche, il y a quelques mesures simples qui peuvent éviter certains abus :
> * Notifications par mail lorsqu'une personne change de groupe (notifier le bureau, ou carrément notifier les gens qui sont déjà dans le groupe, utile par exemple pour un groupe adminsys)
> * Empêcher de modifier ses propres groupes ?
Mis à jour par Baptiste Jonglez il y a plus d'un an
Avec le passage à AbstractUser, on peut désormais utiliser les groupes Django pour donner l'accès à certaines applications et pas d'autres (facturation, membres, configuration VPN, etc).
Ça doit être possible de créer des groupes par défaut dans une fixture.
> Mis à jour par Baptiste Jonglez il y a plus d'un an
> Avec le passage à AbstractUser, on peut désormais utiliser les groupes Django pour donner l'accès à certaines applications et pas d'autres (facturation, membres, configuration VPN, etc).
> https://docs.djangoproject.com/en/1.7/topics/auth/default/#topic-authorization
> Ça doit être possible de créer des groupes par défaut dans une fixture.
Je ferme, même si l'implémentation retenue n'obéit pas exactemment aux règles proposées dans ce ticket (et est plus générique/granulaire, pour s'adapter à la volonté de chaque FAI).
Géré via #136, et documenté : https://code.ffdn.org/FFDN/coin/src/master/doc/user/permissions.md
Je ferme, même si l'implémentation retenue n'obéit pas exactemment aux règles proposées dans ce ticket (et est plus générique/granulaire, pour s'adapter à la volonté de chaque FAI).
Il est nécessaire de pouvoir cacher certaines informations personnelles concernant un membre à toute personne n'ayant pas une telle autorisation.
L'idée c'est de réserver au bureau l'accès à ces données pour protéger la vie privée des membres de l'association.
Par exemple dans la fiche Membres, Un trésorier a besoin de la partie cotisation (cette vue est très pratique pour voir toutes les cotisations d'un membre donné), date d'adhésion, nom d'usage,...
Par contre l'accès à l'adresse, nom, prénom, n'est pas forcément nécessaire.
https://www.illyse.org/issues/199
Géré via #136, et documenté : https://code.ffdn.org/FFDN/coin/src/master/doc/user/permissions.md
Je ferme, même si l'implémentation retenue n'obéit pas exactemment aux règles proposées dans ce ticket (et est plus générique/granulaire, pour s'adapter à la volonté de chaque FAI).