Concept: Permissions / Access control

[Robin481]

One thing that has been heavily contested over the years is the lack of a fine grained control or permissions.

Currently any user can edit any other user.

We already have some sort of access control for things such as admin since the implementation of the AuthUser.

We want to think about how we could implement permissions on a profile level such that for example one could only edit their own profile.

TODO:

• Think about what kind of permissions would be interesting / needed
• Think about how we could match a profile with a AuthUser
• Think were we would need to adapt the application logic to fit the new user specific permissions
• Think about how we could allow certain users to edit the profile of everyone (e.g. Sales people probably still need to edit other profiles)
• Write tickets that would allow us to implement this fine grained access control

[RandomTannenbaum]

Thoughts Roles:

• Every person can edit profiles they have created.
• We add a new role called "editor" or something. People with this role can edit any profile.
• The admin and conf-admin roles stay the same and can also edit any profile.
• Maybe we can add a new setting to profiles that lets you enter email addresses of other people, which should be able to edit this profile without having the editor role.

How to check who a profile belongs to?

• Every AuthUser has a UID. Maybe we can map that to a new attribute on profiles like created_by.

What we have to change:

• The edit fields of a person should be deactivated if you dont have access to that.

[ManuelMoeri]

Thoughts Roles:

* Every person can edit profiles they have created.

* We add a new role called "editor" or something. People with this role can edit any profile.

* The admin and conf-admin roles stay the same and can also edit any profile.

* Maybe we can add a new setting to profiles that lets you enter email addresses of other people, which should
  be able to edit this profile without having the editor role.

How to check who a profile belongs to?

* Every AuthUser has a UID. Maybe we can map that to a new attribute on profiles like `created_by`.

What we have to change:

* The edit fields of a person should be deactivated if you dont have access to that.

I've got a few questions here I want to talk about with you. Let's talk tmrw and write the Tickets as intended.

[ManuelMoeri]

Thoughts after talking with Robin & Thomas

Since the PuzzleTime sync should (hopefully) be active in the near future the comments from @RandomTannenbaum don't really make sense anymore. Persons now automatically get generated by the delayed job instead of other persons manually.

• Implement CanCanCan since it will be needed for a fine grained access control.
• Every person can only edit themselves. Solve this using the LDAP-username. This can either be directly managed in the Skills Application or can be fetched along the other data from the PuzzleTime API. Make sure to implement this dynamically so everyone using the PuzzleSkills outside of Puzzle can still implement this using something else than LDAP.
• A role called Editor or similar will be needed as well. This role can edit every Person.
• Keep the admin and conf-admin role as they are, but make sure to implement them into CanCanCan.
• Add a role for member coaches so they are able to edit every person in their department
• Finally implement checks for these new roles and disable the edit button (& route) for unauthorized people.

Split up into these storys:

• [x] Implement CanCanCan + re-write existing roles
• [x] Figure out how to get/store LDAP-username effectively and implement logic for every person to edit themselves
• [x] Create editor & member coach role
• [x] Catch up on the frontend by replacing all role checks with CanCanCan