Thaks for summary, just one quick comment where I think it needs clarification
On středa 25. ledna 2017 13:59:57 CET Lukas Zapletal wrote: > Corrections. > > > Why you don't like explicit lock actions? > > I misinterpreted your statements above, looks like we both like > explicit locking. > > > add_permission_to_provisioning_manager (also adds to "manager" role) > > add_permission_to_provisioning_reader (also adds to "reader" role) > > add_permission_to_configuration_manager (also adds to "manager" role) > > add_permission_to_configuration_reader (also adds to "reader" role) > > This was just a copy and paste error ^ anyway. > > I think I was throwing ideas too much, let me summarize my attitude on > the PR and filter out ideas that are nice to have but not part of the > PR effort. What I think the PR should do: > > - the API makes sure we can declaratively identify all permissions > which were added by plugins (for comparison, currently "default_roles" > hash) (*) > - the API deprecates "default_roles" hash providing alternative list > of default plugin roles and permissions > - the API provides a way to work with plugin roles (so Discovery > Manager/Reader will work with the new PAI) > - the comparison "plugin:validate_roles" rake task is modified to work > with the new API (it depends on "default_roles" hash) > > (*) the only change in the worst case is to keep track of plugin names > which are adding permissions so we have a list of plugins and > permissions added > > Nice to have: > > - the API can work fine with locking and cloning proposal > - the API is used both for plugins and core (currently seed script) > - the API can be easily extended to what Ivan proposed (I like the > concept of fine-grained roles) > > I still have strong opinion on modifying main Manager/Reader role, I > don't think the original assumption from the RFE that Manager must > have all permissions is not valid. IMHO if user really expect manager > of everything, then there's this Administrator flag, "a manager user" > is required to have "Manager" role plus "Plugin Manager" for all > plugins. We could provide an example (locked) user called Site Manager > as an example if the issue is understanding that. But this is > non-blocking statement. It's a different view of what is best for the > customer. Manager is not Administrator (common misunderstanding). Administrator can modify settings which is more or less application configuration. We don't allow any non-admin user to do this, there's no permission for it and we explicitly check "user.admin?" in there. There are more exceptions like this, e.g. "Any context" behavior. Also we need to address the use case where you want to have "Manager of Organization A". We allow that by cloning Manager role and assigning the organization to this clone. -- Marek > If we implement a way to automatically add all possible permissions to > Manager (and read permissions to Reader), we could automatically make > sure that Manager/Reader have all the require permissions and adding > to the main two roles is irrelevant. If we take the declaration > approach we are not closing doors to this I believe. -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
