> Ok, we discussed the migration path. We should be (with small changes*) able
> to detect whether users modified existing Manager role. In case they did, we
> would rename them to "Customized Manager" and create new Manager role with
> default permissions but locked. Locked means no changes to filters and
> attributes can be made by user, plugin can extend via plugin DSL. If existing
> Manager role was not changed we just lock it. The same for the Viewer. No
> locking/unlocking actions as we have for templates. If this is acceptable
> migration path, then I think we can start working on it.
Why you don't like explicit lock actions? What you described sounds
little bit complicated and confusing, we will see questions soon like
"why I can't edit my role"? I can foresee bugs when the stack locks a
role for some reason and user is stuck unable to edit a role. Explicit
locking/cloning seems more clear to me.
> Ivan had also a good point with task oriented roles. Once we have locking we
> can add more locked roles like "Provisioning capabilities". And potentially
> revisit automatic adding permissions to locked Manager and Viewer roles so
> they won't get out of sync.
Yeah, note that this is actually the exact opposite of what the patch
is trying to do (put everything into two messy roles). Why not to do
this from the day one? We could actually prevent plugins via the API
to change the Manager/Reader roles any only expose these
"fine-grained" roles, the stack would automatically add every
permission also into Manager/Reader. Let me suggest such an API:
add_permission_to_provisioning_manager (also adds to "manager" role)
add_permission_to_provisioning_reader (also adds to "reader" role)
add_permission_to_provisioning_manager (also adds to "manager" role)
add_permission_to_provisioning_reader (also adds to "reader" role)
...
This will not exist:
add_permission_to_manager
add_permission_to_reader
To put this one step furtner, plugins could register their own roles:
register_plugin_role("Discovery") (creates locked "Default Discovery
Manager/Reader" roles and also creates DSL methods
add_permission_to_discovery_manager/reader methods)
This will actually force plugin users to put permissions into these
sub-roles. We could refactor also core permissions in this way
providing similar API when seeding the core roles. Both main roles and
subroles will be explicitly locked by default and users are requested
to clone before modifying them, together with comparison tool we have
a very good user experience.
> *small changes means we extract hashes of permissions in seeds to some
> constant so it's available without running seeds and extending existing plugin
> DSL method "role" so we know whether plugin extends existing Manager/Viewer
> role or user did it manually.
Yeah, this could be even a DSL that is very same as plugins would use.
--
Later,
Lukas @lzap Zapletal
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
