Grouper Developers Forum

[Chris Hyzer <>]

> To clarify a bit, my concern is focused on the narrow issue of
> potentially conflicting ways that the membership of a given group is
> managed. We already have a mechanism to manage that, and I didn't
> recognize a new requirement that it didn't already meet. I'd prefer to
> avoid having to build special infrastructure within the grouper api
> that would be necessary to enable loaders to do whatever they need to
> do, however they need to do it. I suspect that such measures would tend
> to reduce the freedom otherwise open to loader designers. So, I don't
> propose anything that would interfere with your scenario, Gary, but
> neither do I propose anything that might promise to make it easier
> somehow.

You are talking about the existing mechanism as update permissions right?

I think it would be nice for UI users to have a clue as to why the group is 
not editable.

So if the group is not editable because it is a manually entered group and 
the user doesn't have permissions that is one thing.
If the group is not editable because it is a auto-loaded group that is 
another thing.

Im not sure how a grouperLoader type is limiting.  If an installation doesn't 
want to use that type, then they do their loading another way and they are 
not limited, right?  The type is loaded when starting the grouperLoader, so 
they wouldn't even know about it.  Please clarify so I can understand.

Gary raised another point, if there is a daily loaded group, perhaps a wheel 
group user would want to add a member to the source system, then add it to 
the grouper ui, so that the person will be added to the group quicker, and 
the loader will be fine with it.  Another reason that the user needs to know 
about if a group is a loader group or not (again, not necessarily due to 
grouperLoader type, but however we "flag" it)

Also, this discussion makes me think of a new requirement for hooks, a 
context.  The hook should know if the execution is UI, WS, GSH, etc, and it 
should know who is in the grouper-session, and maybe who the actAs is if it 
is a proxied execution, etc.  Could be useful.

Thanks,
Chris