Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] grouper membership loader

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] grouper membership loader

Chronological Thread 
  • From: Chris Hyzer <>
  • To: Tom Barton <>, "GW Brown, Information Systems and Computing" <>
  • Cc: Grouper Dev <>
  • Subject: RE: [grouper-dev] grouper membership loader
  • Date: Tue, 29 Apr 2008 13:36:52 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

> 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.


Archive powered by MHonArc 2.6.16.

Top of Page