Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Permission Based Access Control #45

Closed
svenseeberg opened this issue Oct 25, 2018 · 4 comments · Fixed by #150
Closed

Permission Based Access Control #45

svenseeberg opened this issue Oct 25, 2018 · 4 comments · Fixed by #150
Assignees
@timobrembeck
Labels
💡 feature New feature or request
Milestone
Base Functionality

Comments

@svenseeberg
Copy link
Member

svenseeberg commented Oct 25, 2018 •
edited

THIS NEEDS TO BE DISCUSSED: Do we want to differentiate roles and groups or just have one of them?

Each part of the CMS requires specific privileges. These should be collected in roles. Roles are then assigned to users.

Roles:

  • Superadmin
  • Admin (for single site) (Verwalter)
  • Trusted (is allowed to publish pages / events)
  • Events (is allowed to create/edit events)
  • Pages (is allowed to create/edit pages)

Additionally, it must be possible to allow some users to edit pages in parts of the tree without assigning the role "Pages".
@svenseeberg svenseeberg added the 💡 feature New feature or request label Oct 25, 2018
@svenseeberg svenseeberg added this to the Proof of Feasability milestone Oct 25, 2018
@svenseeberg svenseeberg mentioned this issue Oct 25, 2018
Closed
@sascha11110
Copy link
Contributor

We also need a role that only allows the management of events.

@michael-markl
Copy link
Member

It would be nice to already have a list of all privileges (we could make this a part of our github wiki). A first draft:

Per Site:

  • (CRUD pages): Read, create, update and delete pages (without changing publication status)
  • (P pages): Publish (and unpublish) pages
  • (CRUD events): Read, create, update and delete events (without changing publication status)
  • (P events): Publish (and unpublish) events
  • (CRUD pois): Read, create, update and delete pois (without changing publication status)
  • (P pois): Publish (and unpublish) pois
  • (PN): Send push-notifications
  • (E): Enable or disable extras
  • (GD privileges): Grant or deny users privileges for this site

General:

  • (C user): Create user in the system
  • (R user): Read user details in the system
  • (UD user): Update and delete users

These privileges would be collected in the roles:

  • Superadmin (any) (any on any Site)
  • Admin of a Site (GD privileges) (C user, R user)
  • Manager of a Site (P pages, P events, P pois, PN, E)
  • PageAuthor of a Site (CRUD pages, CRUD pois) ()
  • EventsAuthor of a Site (CRUD events, CRUD pois) ()

Do we need the ability to grant privileges for specific pages/events/pois? E.g. some external organization could only edit its corresponding page(s)? I think we once said, that we don't do that, but I'm not quite sure anymore.

Anything else I forgot?

@sascha11110
Copy link
Contributor

Do we need the ability to grant privileges for specific pages/events/pois

Daniel and Fritjof mentioned that it is used in some cities

@timobrembeck timobrembeck removed this from the Proof of Feasability milestone Mar 16, 2019
@svenseeberg
Copy link
Member Author

Timo and I discussed how to implement site-specific permissions. There are 2 approaches:

  1. For each site (region) there is a corresponding group that has the required privileges for a this specific site. These groups would be "special" to other groups by their 1:1 relationship to the site specific privileges.

  2. For each user we can directly create 1:N or M:N relationships to sites.

There are some problems in general: for example when editing a page, we need to check if the user is allowed to edit pages in general, and second, if the user is allowed to edit a page for this specific site. We could, for example, create our own permission-checking-function that automatically checks for the site-permission.

This definitely needs more discussion :)

@svenseeberg svenseeberg added this to the Base Functionality milestone Jun 7, 2019
timobrembeck added a commit that referenced this issue Jun 12, 2019
@timobrembeck
Add permission-based access control (fixes #45)
382642f 
- Add permissions to models:
    - Add 'manage' permissions for all models, which don't need CRUD fine-grading
    - Add 'view', 'edit', 'publish' permissions for events and pages
    - Add 'view', 'edit', 'send' permissions for push notifications
    - Add 'view' permission for feedback
- Add access control to views:
    - PermissionRequiredMixin for all class-based views
    - @permission_required for all view functions
    - user.has_perm for all action based permissions inside views
@timobrembeck timobrembeck mentioned this issue Jun 12, 2019
Merged
@timobrembeck timobrembeck changed the title Role Based Access Control Permission Based Access Control Jun 12, 2019
timobrembeck added a commit that referenced this issue Jun 12, 2019
@timobrembeck
Add permission-based access control (fixes #45)
8683d51 
- Add permissions to models:
    - Add 'manage' permissions for all models, which don't need CRUD fine-grading
    - Add 'view', 'edit', 'publish' permissions for events and pages
    - Add 'view', 'edit', 'send' permissions for push notifications
    - Add 'view' permission for feedback
- Add access control to views:
    - PermissionRequiredMixin for all class-based views
    - @permission_required for all view functions
    - user.has_perm for all action based permissions inside views
timobrembeck added a commit that referenced this issue Jun 26, 2019
@timobrembeck
Add permission-based access control (fixes #45)
7491432 
- Add permissions to models:
    - Add 'manage' permissions for all models, which don't need CRUD fine-grading
    - Add 'view', 'edit', 'publish' permissions for events and pages
    - Add 'view', 'edit', 'send' permissions for push notifications
    - Add 'view' permission for feedback
- Add access control to views:
    - PermissionRequiredMixin for all class-based views
    - @permission_required for all view functions
    - user.has_perm for all action based permissions inside views
timobrembeck added a commit that referenced this issue Jun 27, 2019
@timobrembeck
Add permission-based access control (fixes #45)
dff05a2 
- Add permissions to models:
    - Add 'manage' permissions for all models, which don't need CRUD fine-grading
    - Add 'view', 'edit', 'publish' permissions for events and pages
    - Add 'view', 'edit', 'send' permissions for push notifications
    - Add 'view' permission for feedback
- Add access control to views:
    - PermissionRequiredMixin for all class-based views
    - @permission_required for all view functions
    - user.has_perm for all action based permissions inside views
@timobrembeck timobrembeck self-assigned this Oct 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@timobrembeck timobrembeck

Labels
💡 feature New feature or request
Projects
None yet
Milestone
Base Functionality
Development

Successfully merging a pull request may close this issue.

Permission-based access control digitalfabrik/integreat-cms
4 participants
@michael-markl @sascha11110 @svenseeberg @timobrembeck