Marek Hulán <[email protected]> writes: > On úterý 24. ledna 2017 0:02:15 CET Ivan Necas wrote: >> Lukas Zapletal <[email protected]> writes: >> >> If you're concerned about the permissions table, this does not help. >> >> Permission are created there by plugin. If the permission is removed >> >> later, it should be removed from all roles anyway, user could already >> >> assign it to both core and plugin role. >> > >> > Down below. >> > >> >> I suppose you wrote a migration that unassigned this permission from all >> >> filters and removed the permission from permissions table. Why does this >> >> not work for core? >> > >> > I agree that technically no difference, but ability to have a list of >> > default roles and permissions (what I call "pull mechanism" but >> > basically its a list or hash of these) allows us to audit this. It's >> > something we already have today (hashes for core is in seeds, hashes >> > for plugins can be added via the existing API hash mentioned). I >> > simply think that we lost track of this when we will be creating new >> > permissions for existing roles via this call (usually in engine.rb). >> > >> >>> I really think we need to say "this is by design, add required roles >> >>> which are provided by plugins" here. Not all RFEs are valid. >> >> >> >> IMHO this is usability issue. And therefore valid RFE. >> > >> > Sure, I made it to extreme, but I am trying to put the requirement >> > from the RFE on weights together with above. >> > >> >> I read your counter-proposal (I don't think it's "counter" :-) If I >> >> understand it correctly, we could break i down into following steps. >> >> 1) add DSL to extend core roles >> >> 2) make core roles locked for editing >> > >> > Locking is indeed nice, but it does not solve my concerns above - lost >> > track. But I like it, let me build on top of that: what if the API was >> > adding the permission twice - once into the core (locked) role and >> > once into "PluginName Manager/Reader" (locked) role as a copy. So >> > users could decide what to include for their Users or UserGroups. This >> > could keep some flexibility and also enable better audit. The API >> > would be responsible for copying them so plugin authors would not >> > care. >> > >> >> 3) add DSL to remove permissions from roles >> > >> > I don't insist on this one, removing permissions can be done via >> > migrations as you noted. This only makes sense if it's actually better >> > to have such an API method(s). It might end up in situation when >> > migration would have been much more easier and cleaner - then this is >> > a no go of course. >> > >> >> I find the locking better since it's similar concept to templates where >> >> we >> >> have the same problem. But I like the proposal in general for future >> >> plugin >> >> uninstallation. If audit can't give us the answer we should start >> >> tracking it, ideally the same way for all resources created by plugin. >> > >> > Sure, locking is a good start, my biggest concern was to have a role >> > (e.g. Manager) modified by core, plugins, users. Three individual >> > subjects, locking should help here. >> > >> > If locking is the thing we agreed here, I vote for implementing it >> > with the new API so we are clean from the day one. Technically we can >> > make the upgrade easier if we decide to create new locked roles with >> > names like "Default Manager" and "Default Reader" (or Viewer not sure) >> > keeping the original "Manager" and "Reader" unchanged. If we also >> > implement a comparison tool, that is huge improvement in user >> > experience IMHO. >> >> Let me offer a bit different view on this. When looking at the >> permissions from user perspective, they are very granular. This is great >> when you need to achieve something really specific, but most of the >> time, viewer (read only access), user (use the feature) and manager >> (configure the feature) could work for 80% of users that need something >> more than just admin. >> >> Therefore, I wonder if we should not start thinking about grouping >> permissions based on features they are related to and scope of power, >> and then let the roles to be build using this metadata. >> >> Example: provisioning permission group would contain Host, Domain, Compute >> Resource, Image… permissions. Orthogonal to the feature, the permissions >> would also have a flag, if they are meant for viewer, user or manager >> (the same decision you make if you put the permission in core/plugin >> viewer/manager role) >> >> In a role, instead of putting the individual permissions there directly, >> I would say, using this role, I want to be able to use provisioning, so >> including the viewer and user permission from provision group. The >> permission groups would be controlled by the code (not users). What >> users could do, when including a specific permissions group, would be to >> say if they want opt-in/opt-out specific permission. I expect, most of >> the time people would trust the developers to put the right permissions >> into the features and scopes. >> >> The similar way, I could add OpenSCAP permission, rex permissions, >> Puppet permissions… And the default manager/viewer roles would have by >> default corresponding groups from all features. >> >> I know it's a bit more work, but it would help not only the people that >> are happy with defaults, but it would help the whole permissions model. > > Thanks for another idea. I wonder whether it functionality wise differs from > locked roles and using user groups to group such roles. Honestly I don't > think > introducing one more entity to the whole stack would help. Also while we talk > only about roles - permissions relation it's not always that simple. Note > that > each permission is always assigned through a filter which can define > condition > and taxonomy restriction. So when permission group would be assigned to role, > we'd need to clone all permissions and let user to configure filters? And in > such case how would we keep it in sync with later permission group > changes?
I'm looking at the permissions groups more as metadata around permissions and when using in role, it would mean defining a recipe/rules for what permissions you want to have in the role: so instead of being the container for permissions, it would say, what permissions should be added to the role. Using this rules, it would be possible to add additional permissions later from the code and things would just work (tm). Once the permission is added to do role though the permissions group, it would work exactly as the permissions work today. I agree that adding the filter behavior to the permissions group would not help in making it simpler and that was not the attempts. -- Ivan > > -- > Marek > >> >> -- Ivan > > > -- > 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. -- 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.
