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

feature(Roles & Permissions): initial support #2111

Closed

Conversation

webteckie
Copy link
Contributor

@webteckie webteckie commented Jan 17, 2016

Initial support for roles and permissions in keystone (a possible approach for solving #803). This PR mainly addresses defining a role and permissions model and based on this restricting Admin UI menus, list, and items per allow role/permissions. Please see gist at https://gist.github.com/webteckie/139c0303eaac1179290d for instructions on including support for roles and permissions in your application. This is definitely WIP and mainly putting out for review and comments and whether the approach makes sense. The main thing left to do is to add support for restricting server side list operations based on the configured user roles/permissions.

For reference, here are some screen shots of how this would look in the admin ui:

Roles screen:
image

Permissions Screen:
image

@adamscybot
Copy link

Super interested in this. Something I have needed also. Gonna give it a read over when I get a chance to see how it would fit with some use cases I've come across.

@ericelliott
Copy link
Contributor

Permissions are definitely a necessary feature.

I'd like to hear what @JedWatson has to say about it, specifically, what are the key requirements, and does this proposal fill them?

Quick note on the failure, this is failing on Node 0.12.x, but works on 4.0. We're not testing 5.x, but probably should be.

@webteckie
Copy link
Contributor Author

I don't plan to do anything else with this until @JedWatson gives a direction on it.

@mxstbr
Copy link
Collaborator

mxstbr commented Mar 18, 2016

I think this is a must-have feature for a 1.0 release. I'm inclined to move this forward to be merged soon after we release 0.4 (so we don't delay that release even more), but if we can get this ready before 0.4 is finished even better. I'll poke Jed to share his thoughts on the direction of this asap!

@mxstbr mxstbr added this to the 1.0.0 milestone Mar 18, 2016
@morenoh149
Copy link
Contributor

I think @webteckie expressed interest in a solution leveraging https://github.com/seeden/mongoose-hrbac and https://github.com/seeden/rbac in the slack channel (as it would integrate pretty easily with mongoose). Either way roles and permissions are one of the most requested features.

@webteckie
Copy link
Contributor Author

Initially I started trying to hook in https://github.com/seeden/rbac and quickly abandoned the idea since I think it may prove easier to slowly develop keystone's own rbac API around its list modeling. Instead of focusing in the API, I decided to focus on the Admin UI side of things disabling access to admin parts and entities based on some rbac view model as well as the based on the currently signed in user. I also would like the feasibility of being able to do all rbac config via the admin UI and I was able to prove with the approach I took that that is easily doable. Hopefully we can get some consensus on this and move forward with an approach that handles most user needs :-)

@astr0sl0th
Copy link

If I pull from the main repo will this be available?

@wmertens
Copy link
Contributor

This is nice, but I'm afraid it won't be specific enough. Imagine for example a list of blog posts, where only the original author can edit the post, or maybe documents where you get access to more fields depending on your user level.

I think this means that there should be a callback system where you can override the results of the default ACL.

Also, perhaps it would be good to make a list method .findFor() which expects a Viewer (User) object as the first argument, with zero permissions assumed by default.

matthieugayon added a commit to matthieugayon/keystone that referenced this pull request Jul 19, 2016
@VinayaSathyanarayana
Copy link

Any Updates on whether this is being taken up?

@JedWatson
Copy link
Member

@VinayaSathyanarayana see keystonejs/keystone-test-project#21 for discussion on some underlying features I'm proposing

@arturkasperek
Copy link

@webteckie It would be super if you resolve conflicts

@webteckie
Copy link
Contributor Author

@arturkasperek please see keystonejs/keystone-test-project#21

I believe that's what the initial support will be.

@VinayaSathyanarayana
Copy link

Any update on this?

@Tushar-Gupta
Copy link

Any update on this? Really need this feature for my project.

@vamshi9
Copy link

vamshi9 commented Feb 4, 2018

Is it working? Can I give a try on this? Or should I go with creating other user model and create separate admin panel for users

@vinicius-ronconi
Copy link

Any update here?

@luismsaraiva
Copy link

Can you update this to the latest version of KeystoneJS? Cheers

@nvs2394
Copy link

nvs2394 commented Sep 17, 2018

@here Any update here ?

@GreenMonkeySaveEarth
Copy link

Any update on this? Need this badly.

@JedWatson
Copy link
Member

This isn't going to land in v4, but is implemented in v5

@JedWatson JedWatson closed this Apr 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.