Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Namespace Transition

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Namespace Transition


Chronological Thread 
  • From: Tom Barton <>
  • To: Shilen Patel <>
  • Cc: Chris Hyzer <>, Grouper Dev <>, "" <>
  • Subject: Re: [grouper-dev] Namespace Transition
  • Date: Wed, 31 Dec 2008 08:51:38 -0600

Shilen Patel wrote:

On Dec 31, 2008, at 1:45 AM, Chris Hyzer wrote:

I made a doc on grouper aliases (i.e. name history):

https://wiki.internet2.edu/confluence/display/GrouperWG/Grouper+aliases

Also, what does this mean?

copies are made to flesh out some scheme. For this, the copies have new
identifiers and would optionally inherit memberships held by template
elements.

You mean if someone is a member of a group which is copied, then that subject should be a member of the new copy of the group? Agreed

And/or do you mean that if the group being copied is a member of another group or list, that the copy of the group should be a member of the group or list? Unless there is a good reason for this, I'm not sure I agree with this. Though if optional, then the caller can decide.


I wonder if somebody would intentionally create a template group that is a member of other groups and would want those memberships to remain if the group is copied. For instance, say if a school creates a set of template groups that are used for all biology courses. One of the template groups may be a member of an all_biology_students group.
If it's optional, should it be true or false for all memberships of the group or should we allow the users to specify a different option for each membership or each type of membership? Somebody might want this option to be different for access privileges vs member lists. I think this question would apply to both members of the group being copied and also groups that the copied group is a member of. But maybe that's making this more complicated than it should be...

If we're going to support any options for a group copy operation, I don't see a huge problem with ensuring that the set of options is "complete". We agree that there should be some options, so perhaps we shouldn't skimp.

For a UI, I can imagine a form with check boxes that each select/deselect one optional aspect of the copy operation: access privs, memberships (ie, groups the source group belongs to), members (ie, Subjects belonging to the source group), and a checkbox for each extended list attributes. Non-list non-system-maintained attributes should just be copied - yes? Then there's the question of identifying the set of groups to which the specified copy operation should be applied...

Tom



Archive powered by MHonArc 2.6.16.

Top of Page