-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Conversation
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. |
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. |
I don't plan to do anything else with this until @JedWatson gives a direction on it. |
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! |
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. |
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 :-) |
If I pull from the main repo will this be available? |
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 |
Any Updates on whether this is being taken up? |
@VinayaSathyanarayana see keystonejs/keystone-test-project#21 for discussion on some underlying features I'm proposing |
@webteckie It would be super if you resolve conflicts |
@arturkasperek please see keystonejs/keystone-test-project#21 I believe that's what the initial support will be. |
Any update on this? |
Any update on this? Really need this feature for my project. |
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 |
Any update here? |
Can you update this to the latest version of KeystoneJS? Cheers |
@here Any update here ? |
Any update on this? Need this badly. |
This isn't going to land in v4, but is implemented in v5 |
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:
Permissions Screen: