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.

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

Add read-only access level #1287

Open
maneesha opened this issue Jul 6, 2018 · 9 comments

Comments

Projects
None yet
2 participants
@maneesha
Copy link
Contributor

commented Jul 6, 2018

We have some users who should have access to view data but should not have access to edit anything.

@pbanaszkiewicz

This comment has been minimized.

Copy link
Contributor

commented Jul 6, 2018

@maneesha would that be view access to all pages or just some pages?

@pbanaszkiewicz pbanaszkiewicz added this to the v2.0 milestone Jul 6, 2018

@maneesha

This comment has been minimized.

Copy link
Contributor Author

commented Jul 6, 2018

@pbanaszkiewicz I was thinking this would be for all the user groups we currently have - we would have the option to set permissions to be read only or write.

@pbanaszkiewicz

This comment has been minimized.

Copy link
Contributor

commented Jul 21, 2018

Django supports group permissions, and for the most part we used them to control if user for example is able to create, change or remove some model's objects. However, "view" permissions are only just now coming to Django 2.1 (to be released soon).

I'd propose we wait until Django 2.1 is released, then adapt it.

@pbanaszkiewicz

This comment has been minimized.

Copy link
Contributor

commented Dec 29, 2018

I thought about this issue and decided to move it to the v2.5 release. This will require deep testing and thinking, and possibly some design decision from The Carpentries staff. It's too late in v2.4 release to implement this feature.

@pbanaszkiewicz pbanaszkiewicz modified the milestones: v2.4, v2.5 Dec 29, 2018

@maneesha

This comment has been minimized.

Copy link
Contributor Author

commented Jan 2, 2019

Thanks @pbanaszkiewicz
Right now it looks like we can set view permissions to individual sections. I haven't actually done this so I don't know how it works -- and the hope here was to do this in groups, rather than clicking through each "view" option one by one.

See for example - it looks like I could set someone up to be able to add, change, delete or view an object.

image

@pbanaszkiewicz

This comment has been minimized.

Copy link
Contributor

commented Jan 2, 2019

Hello @maneesha,

you can assign specific permissions to groups in Django admin. Right now we have these groups:

  1. administrators
  2. steering committee
  3. invoicing
  4. trainers

Apart from these we also have people marked as "superusers", which means they have all the permissions available - even if not assigned.

It would help me a lot if you described now what groups do you want to have and what their initial permissions should be.

On a later stage I have to make AMY functions listen to these new permissions, because for now they mostly use "add/change/remove" permissions.

@maneesha

This comment has been minimized.

Copy link
Contributor Author

commented Jan 2, 2019

Thanks @pbanaszkiewicz
Right now if we give permissions to a group, that group gets read and write access.
When assigning permissions to a group, would it be possible to choose whether they get read only access or read/write access?

We do want to re-think each of our groups - you are right about that. That may be a separate issue. I'll think about that more an open another issue for staff discussion. When I opened this issue I wanted to see if read-only access was generally possible.

@pbanaszkiewicz

This comment has been minimized.

Copy link
Contributor

commented Jan 2, 2019

@maneesha:

When assigning permissions to a group, would it be possible to choose whether they get read only access or read/write access?

Yes. You can mix & match the permissions for groups the same way as you can for individual persons. For example, group "Trainers" may have add&view&change&remove permissions to TrainingRequests objects, and only view access to Membership objects.

It may be necessary to create custom permissions, like "read trainees" or similar - I have yet to dive into the code to decide.

We do want to re-think each of our groups - you are right about that. That may be a separate issue. I'll think about that more an open another issue for staff discussion.

I'll gather functions that we have in AMY and provide you with the list, so that you can decide what permissions you need for each group. I have to do this to determine if there are any custom permissions to create.

@pbanaszkiewicz pbanaszkiewicz modified the milestones: v2.5, v2.6 Feb 2, 2019

@pbanaszkiewicz pbanaszkiewicz modified the milestones: v2.6, v2.7 Feb 28, 2019

@pbanaszkiewicz pbanaszkiewicz removed this from the v2.7 milestone Mar 30, 2019

@maneesha

This comment has been minimized.

Copy link
Contributor Author

commented Jun 24, 2019

This is part of a larger conversation of who should have access to read/write various AMY components. We will return to this in an upcoming work cycle.

@maneesha maneesha closed this Jun 24, 2019

@maneesha maneesha reopened this Jun 24, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.