grouper-dev - RE: [grouper-dev] grouper membership loader
Subject: Grouper Developers Forum
List archive
- From: Bill Kasenchar <>
- To: Chris Hyzer <>, Tom Barton <>, "GW Brown, Information Systems and Computing" <>
- Cc: Grouper Dev <>
- Subject: RE: [grouper-dev] grouper membership loader
- Date: Tue, 29 Apr 2008 14:29:02 -0400
- Accept-language: en-US
- Acceptlanguage: en-US
I think type is very useful in the UI to keep things in context. If you use
UPDATE it would confuse users and it would also imply that someone could have
the same privilege level as the loader and that would result in unexpected
behavior
-----Original Message-----
From: Chris Hyzer
[mailto:]
Sent: Tuesday, April 29, 2008 1:37 PM
To: Tom Barton; GW Brown, Information Systems and Computing
Cc: Grouper Dev
Subject: RE: [grouper-dev] grouper membership loader
> 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
- grouper membership loader, Chris Hyzer, 04/28/2008
- Re: [grouper-dev] grouper membership loader, GW Brown, Information Systems and Computing, 04/28/2008
- Re: [grouper-dev] grouper membership loader, Tom Barton, 04/28/2008
- Message not available
- Message not available
- RE: [grouper-dev] grouper membership loader, Chris Hyzer, 04/28/2008
- Re: [grouper-dev] grouper membership loader, Tom Barton, 04/28/2008
- RE: [grouper-dev] grouper membership loader, Chris Hyzer, 04/28/2008
- RE: [grouper-dev] grouper membership loader, GW Brown, Information Systems and Computing, 04/29/2008
- Re: [grouper-dev] grouper membership loader, Tom Barton, 04/29/2008
- RE: [grouper-dev] grouper membership loader, Chris Hyzer, 04/29/2008
- RE: [grouper-dev] grouper membership loader, Bill Kasenchar, 04/29/2008
- RE: [grouper-dev] grouper membership loader, Chris Hyzer, 04/28/2008
- Re: [grouper-dev] grouper membership loader, Tom Barton, 04/28/2008
- RE: [grouper-dev] grouper membership loader, Chris Hyzer, 04/28/2008
- Message not available
- Message not available
Archive powered by MHonArc 2.6.16.