Role based Admin System
planned
Jared Collier
If multiple roles were available in the admin UI, it would open the door to create a much more robust CMS system, and would pave the way for the following:
- Restricted access on certain fields/document types (great for companies that trust some employees with only specific tasks, but still need them to be administrators). This could be used two ways, one would be to hide fields/documents, the other would be to make them visible but not editable.
- Groups to place admin users in to restrict their access/open the door for a document pipeline.
- Document pipeline for things that need to be approved by multiple groups or individuals before going live. The default would be no additional approvals, save makes the information live, but an n-length chain could be created forcing a new document to pass through one or more group/individual approvals before it becomes live
Thomas MacLean
If you just want to hide models based on fields in the current user object, I created a Gist that does just that:
https://gist.github.com/tmaclean-LV/919886cb2830da6a5710d35abbce46f4
The navigation rebuild after changing a user's permissions isn't perfect, as unhidden content types will be shown under "other" until you restart Keystone. Also, users can still technically access these models, they just won't see them in the UI. Still, it's a something!
laterdude
I've implemented webteckie's workarounds and fumbled around with the list-based permissions Jed suggests in #21, and it would be awesome to have some idea of when some sort of consensus might emerge on this feature. I'd love to migrate several government Drupal 7 sites over to keystone, but the lack of a clear idea on the what/how/when/core implementation of this feature might be has made others on my team somewhat concerned that things would break rather quickly down the line and the api would become unusable for future devs should we proceed with our own solution. Great project otherwise, can't say enough good about it. Would just be great to know if there's some direction things seem to be pulling in since September.
Jed Watson
I've created a proposal on how this could be implemented in the test project: https://github.com/keystonejs/keystone-test-project/pull/21
It's not built-in roles, but it's the underlying support that would let developers implement very flexible roles (or other permissions models) in the Admin UI. Would love some feedback.
This post was marked as
planned
Jake Stockwin
Would be great if this also enabled multi site support. I.e. allowing multiple sites from one keystone instance, with distinct users for each site, who can access the admin ui for their own site only.
Sharad Kumar
Agree with Jake. It would be really useful on a number of use cases for me to build serious apps on KS if I am able to create multi-tenant (sites) apps on KS/admin. I think two key features are:
- Ability to partition database/admin experience on a key such as siteId internally added for all reads and writes and users. So if user1 from site1 logs in, he can read/write data where siteId=site1.
- Ability to setup authorization at list (and collection) and field level. So I can define roles such as user, admin, buyer, seller etc. Each having access to read/write based on role authorization.
- Ability to setup admin navigation/ux to have custom actions, custom screens within admin UI "shell". This will enable ability to surface custom scenarios essential for any serious use cases or MVP. It will get us using Keystone for production uses cases that are varied and get us started quickly.