> I tend to agree, I started to summaries my thoughts here(wip):
>
>
http://theforeman.org/projects/foreman/wiki/Organization-Groups-Design
>
> thanks!
> Ohad
>
Following my discussion with Ohad on IRC, I post my proposal here:
I don't particularly like the name "Organization", it makes me think of
companies rather than a physical/logical hierarchy/classification of stuff.
Organization Unit is too close to Business Unit too, IMHO.
Looking at synonyms of synonyms I suggest: grouping, structure,
arrangement, layout, component, bunch, element, part, bundle, collection,
gathering, ensemble, entity,
categorization/classification/combination/composition/division, fragment
Using composed words may help making things clearer.
Here is how I see things, focusing on permission management:
In a nutshell:
Users can be nested into groups, which nest too; similar thing with Orgs;
you then match the two sets with a given {Role;Filter} couple.
The long version, with grammar equivalent:
Users COULD be grouped inside Groups, that COULD themselves be grouped into
new Groups (preventing recursion). We could call all of them Persons
(either physical (Users), or moral (Groups)).
Person: group|user
group: Person*
Proxies, Computes, Media, Domains, Hostgroups, Environments, Subnets,
Hosts, Users, etc. are Items. Some Items COULD be grouped inside Entities.
Entities are Items too, hence can be contained in other Entities too
(preventing recursion).
Note that persons are entities too, you can manage them too through some
permissions.
Entity: Entities | Person | proxy | compute_resource | media | domain |
hostgroup | environment | subnet | host
Entities: Entity*
We now have two ensembles of things we would like to interconnect with
right restrictions. Permissions (like edit_host, create_compute, etc.) are
grouped granted in Roles.
Role: permission*
Filter: Entity | bookmarks | search_string
The solution I see would GRANT some rights TO a Person ONTO an Item, using
a particular Role-Filter couple.
GRANT Role TO Person ONTO Filter+
But the logic coded inside Filters may be interesting to reuse, so it may
also be used INSIDE Filters or Roles.
FilterExpression: Filter | FilterExpression (AND | OR | XOR)
FilterExpression | NOT FilterExpression
FilteredPermission: permission [ONTO FilterExpression]
Role: FilteredPermission*
GRANT Role TO Person ONTO FilterExpression
Notes:
This could/should be simplified, eventually merely to fit properly inside a
simple web form.
"ONTO FilterExpression" specifies the matching objects that are accessible
with the granted permissions.
I was thinking to add a "IF FilterExpression" to FilteredPermission, that
evaluates to true if the current user has somehow access to the resources
FilterExpression resolves to.
We already have group nesting support.
My Entities really are Organizations, but I don't think this name really
suits (entities may not be the best term either).
From Ohad Levy <ohadlevy@gmail.com>:
> org should also have default values, that we could remove the non app
> related settings from the hostgroups
(I am merely reporting, I didn't understand what he meant :-P)
From the wiki page:
> should hosts belong to more than one org?
I am sure it would be very beneficial.
Just like you may need to manage them both by BusinessUnit, OS, type of
instance, and location,
you may want to allow different permissions to the same host to different
persons, each having one or more rights (granted by roles, onto orgs).
Thinking of whitelist and blacklist filters (the broken "plus all" and
"must be" select beside the filters):
It is similar to "granting" and "denying" filters.
If used as "granted actions MINUS denied actions", with granted actions
being OR-ed together from the whitelist and denied actions being OR-ed
together too from the blacklist,
the denied actions will prevail and clobber everything else, being counter
productive and misleading.
If used a la Apache HTTPD, the previous would be similar to using "order
allow, deny" (granting no rights by default, adding the mentioned rights,
then removing the other mentioned rights).
If we use a "order deny, allow" approach, we would first grant all rights,
then restrict rights, then extend rights.
The fact that all rights are granted by default seems completely wrong and
dangerous, right restriction would be complex too.
This is why I proposed FilterExpression above, with AND/OR/XOR/NOT
capabilities.
As we plan on using search strings in filters, this would almost come for
free.
Cheers,
···
2012/8/1 Ohad Levy
--
Olivier Favre
www.yakaz.com
I generally like the direction we