I am really, really liking the RBAC (role based access control) as both a developer and a user. It has the granularity to really lock things down in good ways. There is, of course, some more work to do in hooking it up under the hood. The UI too is functional but gets slow to use for complex roles (the API is much better for manipulating roles at the moment).
One question I have is, would it make sense to move the organizations and locations up to the role level? Right now each filter has its relation to orgs and locations.
As a reminder, a Role has many Filters and each Filter has many Permissions.
From a user point of view, I am finding myself wishing to create Roles that are associated with organizations. For example, a role that allows editing of provisioning templates in organization Datacenter. To do this, I would add the Datacenter organization to each of the handful of filters for this role.
Instead, from an user interface perspective (either the web UI or the hammer CLI), I could add functionality that enforced that filters in a role all have the same organizations and locations. The data model under the hood would not necessarily even have to change; we could just implement this as a "best practice" through the UI and CLI. (We could, of course, change the data model too if desired.)
Are there some use cases where you'd want a single Role that would allow view_domains in organization A and edit_domains in organization B? (In my adjustment, that would be two roles, one for A and another for B.)
···
-- @thomasmckay–
“The leader must aim high, see big, judge widely, thus setting himself apart form the ordinary people who debate in narrow confines.” ~ Charles De Gaulle
“Leadership is about making others better as a result of your presence and making sure that impact lasts in your absence.” ~ Harvard Business School