> Hi,
>
> I think this discussion belongs on foreman-users at first.
> Maybe create a small survey to collect users' feedback about taxonomies to
> see what users like/don't like/use/don't use etc. first so we don't go
> about a major redesign that is not really needed?
> Once we have some feedback from users, we can start here how we need to
> redesign them that is based on actual user data rather then developer
> hunches or specific cases you've dealt with in the past.
While I agree the user feedback is needed here, I don't think
the developers couldn't initiate this. I can just testify that reasoning
about the taxonomies right now is very hard, as we hit this several times
in remote execution: many times, there was some design drafted, it got
much more complicated when taking taxonomies into account. And the level
of complexity grows as one starts reasoning about:
- taxonomies nesting
- orthogonal taxonomies - combination of organizations and locations
The current state leads to developers fighting with the taxonomies
infrastructure or just avoiding using it, because otherwise there would
be too many edge cases with undefined behavior. So from developer point of view
(and I don't think I'm and exception here), the taxonomies need major redesign.
In general, it seems the taxonomies as they are today try to solve too many
things (or we want to use them for things they were not designed for):
- classification - where the resource lies (physically or logically)
- maybe tagging would be more flexible for this
- multi-tenancy - resources separation
- we are still missing this. What would help here is having one and only one owner for every resource
(parent-relation could still work here). The things be unique by combination of owner tenant and name.
The only role of the tenant would be scoping the uniqueness of the resources. Permissions would be
still build rather in authorization with filters, rather than the tenant dealing with it.
- we are still missing this. What would help here is having one and only one owner for every resource
- authorization - what resources can I see
- since the permissions system is already build around filters, filtering around tags
(and building more user friendly tools around building the permissions: the current model
is very powerful, but hard to use)
- since the permissions system is already build around filters, filtering around tags
Please don't take that as a design proposal, rather as an example of a possible
way we could move to make the things more usable, understandable and deterministic
(or at least where the reasons could be for it not being perceived that way right now).
– Ivan
···
----- Original Message -----On Thu, Jan 14, 2016 at 12:52 AM, Tom McKay thomasmckay@redhat.com wrote:
Does anyone like the way orgs and locs work now? Can we raise the option
of replacing them with something that better meets user expectations?True multi-tenancy - Cannot be done. Locations are not scoped to
organizations. Many resources are not even scopable to organizations.
“Any Context” really means “No Context” - What? Can we make “any” really
mean “any”?I realize that customers have begun to resign themselves to the
awkwardness, but is it really too late to reconsider this decision?I’m super frustrated that so many objects bleed across orgs. Should I
really be able to reference (and change!) a snippet that does not belong to
my org? Should I have to be an admin to manage the scope of what resources
belong to which org? There is no such thing as an “org admin” in terms of
roles and permissions that is actually tenable. I challenge anyone,
especially developers, to run as a user without admin checkbox priveleges.–
–
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.–
Have a nice day,
Tomer Brisker
Red Hat Engineering–
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.