I'm sure there are benefits of a group belonging to groups, but I think
it's outweighed by the complexity involved.
On 20 October 2015 at 13:48, Marek Posolda <mposolda(a)redhat.com> wrote:
That's similar to how it worked for GateIn portal . There was
only
parent-child notion and each group could be identified easily by path
consisting of it's simple name and parent hierarchy. For example root
group "platform" had path "/platform" . The subgroup
"finance" of root
group "platform" had path "/platform/finance" etc.
All the roles were always assigned to user per group, so there was
notion like: User "john" is member of role "admin" in group
"/platform/finance" etc. Visualization was quite easy - some screenshots
are here:
https://docs.jboss.org/author/display/GTNPORTAL39/Manage+Users+and+Groups
.
I think this model was sufficient (at least for portal purposes). Can't
any customer wanted the structure with group being child of multiple
parent groups.
Marek
On 19/10/15 16:40, Bill Burke wrote:
> I was wondering if it would be ok to only have parent/child, tree
> structure relationship between groups. Meaning, a group can't belong to
> multiple groups.
>
> I was just thinking about modeling a large company with groups. How
> would you visualize the group structure within the admin console? A
> hierarchical-only group structure would allow you to define a group with
> a simple non-unique names. i.e. "admins", "customers".
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev