Member list should not be viewable by all members by default

[chris18890]

(cross posted in the Google group)

Currently, all embers can see the members page & browse contact details, including emergency details, for members. This can create Data Protection & privacy issues for spaces whereby members are forced to agree to their details being shared with the wider community, which they may not want.

This is particularly an issue if the registration module is enabled, as anyone could theoretically sign up & have full access to the membership list & contact details.

I propose a modification to the contact & member modules to introduce a _list permission which is not given to the member role by default, only the webadmin & director roles. They can choose to give the permission to members if they wish. The end effect is that members no longer see the members tab at the top of the screen, but can still view their own profile by clicking the profile link at the top right hand of the screen.

Thoughts @elplatt, @ramgarden?

[ramgarden]

That is a very good point. The idea was that any member can see other member's contact info in case of emergency or to get help from them on a project, etc. they can contact them "off list" instead of emailing the whole membership listserve/googlegroup. But if you do have the ability to let just anyone sign themselves up then you are giving away personal info. I wonder if there's already a built in way to configure the "member" role for those paying members to be the only ones able to see the list? Is that a possibility?

[chris18890]

At the moment there's no way that comes to mind to differentiate between paying & non-paying members. There is the "active" filter for checking if dues are up to date, but this is more of a GUI filter than an API-accessible option, and it only covers members whose membership has lapsed/expired (since the last billing cycle, I think, which may require the bill module to be used and run), not necessarily capturing those who have signed up & have yet to pay.

[chris18890]

It is also possible to repurpose the roles for this - by default webadmin & director roles have full permissions (as does the built in admin account) but there's no reason why subsets of permissions could be delegated to different roles. So spaces may want to give all members access to the membership list, others may not, it can be changed relatively easy via the gui by (un)assigning the contact_list & member_list permissions

[ramgarden]

Ah OK so this issue can be solved by updating the wiki/help docs explaining how to set up the roles and permissions to fit the needs of each organization using Seltzer. Right? Is it really just the difference between the "Authenticated" and "Member" roles? So for non-paying members, the admin/secretary would just remove the "member" role from that user/contact and they can no longer see the whole member list? [image: Inline image 1]

On Tue, Nov 21, 2017 at 11:09 AM, Chris Murray notifications@github.com wrote:

It is also possible to repurpose the roles for this - by default webadmin & director roles have full permissions (as does the built in admin account) but there's no reason why subsets of permissions could be delegated to different roles. So spaces may want to give all members access to the membership list, others may not, it can be changed relatively easy via the gui by (un)assigning the contact_list & member_list permissions

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/elplatt/seltzer/issues/404#issuecomment-346075707, or mute the thread https://github.com/notifications/unsubscribe-auth/ACnBzZtkn-Vd_5tnyQptnDTxWXLGZb3Rks5s4vXHgaJpZM4QmBXv .

[chris18890]

How dare you suggest we update the help/wiki when we can just use moar code to solve the problem! :P

Joking aside - yes and no - removing the member role from a user breaks a lot of things - they can no longer view or edit their own info. But the wiki should definitely be reviewed to ensure it explains the permissions & roles set up :)

I'll create the PR & let you have a look at the code :)

[chris18890]

@ramgarden @elplatt have either of you had a chance to review this code? Would like to get it merged soon! :)

[ramgarden]

So we decided there need be a code change for this? Not simply just making sure non paying members had the member role taken away?

On Dec 10, 2017 3:08 PM, "Chris Murray" notifications@github.com wrote:

@ramgarden https://github.com/ramgarden @elplatt https://github.com/elplatt have either of you had a chance to review this code? Would like to get it merged soon! :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/elplatt/seltzer/issues/404#issuecomment-350577751, or mute the thread https://github.com/notifications/unsubscribe-auth/ACnBzUMKH97yGN5r1mA0yaoCALVd3BrOks5s_DpAgaJpZM4QmBXv .

[chris18890]

I believe so - removing the member role would solve the issue for non-paying members seeing the member list, but it breaks a lot of other things as well, as non-paying members couldn't even update their own details or sign up for a membership plan then. It also doesn't solve the issues in a privacy-minded space where even paying members should not have access to the membership list - this codefix solves both those issues :)