Grouper Developers Forum

[Shilen Patel <>]

On 1/7/11 1:33 PM, Chris Hyzer wrote:

Ø  Do you think it might make sense to only look at groups, stems, and attributes that currently exist for these queries?  So for instance, say a group was created on 1/1/2010 that had some memberships and was deleted after a few days.  Then a group (different uuid but same name) got added on 1/1/2011 possibly by somebody else.  If a point in time query is made for all memberships of the group (based on a group name query) that existed on or before 1/2/2011, should that ignore the ones from the prior group that was deleted? 

 

Hmmm…. That is up to you.  I guess the most correct thing to do is to look at any groups with that name at any point in time.  It’s a little confusing since you can lookup a group by uuid or name in the WS.  I didn’t mention this in the wiki, but if you get members on a group which doesn’t currently exist, the lookup will barf.  So either we need the WsGroupLookup logic that does the lookup to look at grouper history if it is a point in time query, or it just need to pass the UUID or name to the API method.   Maybe we should start by discussing the API.  Is there a wiki on this?  A search doesn’t find it…  i.e. is there a way to get point in time members based on group name, which would behave differently than doing it by uuid?  Ie. by uuid it would get just that group while it exists and is deleted.  If created again it would have a new UUID… but name would get all of them.

Yes, you can query based on the group name or the uuid.  Right now the API expects you to pass a uuid.  But since the history includes the group names, you can get all the uuids associated with a group name.  Depending on what we want, I'll adjust the API.

So if a member search is done by group name and there have been multiple groups with that name, there are a couple of things to think about I think...

1.  Security for the prior group.  I'm not sure it makes much sense to look at the privileges of the current group (if one even exists now) or the privileges of the prior group (right before it was deleted?) to determine who can read members of the prior group.  I suppose we could assume you have to be a wheel member or GrouperSystem.

2.  Since the two groups have different uuids, it seems like we would want two different wsGroup objects in the resulting XML and associate the correct subjects with the correct wsGroup.  For Get Members Rest Lite, I don't see a good way to have multiple wsGroup objects in the output without changing the schema of the output.  Though I think this can be done in the non-Lite version by just having multiple instances of WsGetMembersResult.

 

Also, you and I talked about this before, so I thought I would mention again… if some grouper user does some load testing, it will fill up the point in time with junk… I think it would be nice to have a GSH method to be able to remove things from point in time.  i.e. remove a group or some memberships or whatever.  Granted this might make other things not correct, but I think it is up to the Grouper deployer to decide… i.e. if there is a test stem, and you remove it from point in time, then you assume that no real groups use those test groups and need the history…  I think we ended our last discussion by saying that we wouldn’t be able to delete, but I keep thinking we need this feature once the DBA complain that too much space is being used…

Currently, there's a GSH method to delete old point in time records based on a time.   I'll add more methods to take care of the cases you've mentioned and just document that it can make the history wrong if the groups are used elsewhere.

 

Ø  Also, I'm assuming for security that you have to be a current admin of the group.

 

That’s fine with me if its fine with everyone else, as opposed to READ privilege…

Sounds like Jim is voting for read privilege, so I'll go with that unless anybody disagrees. 

Thanks!

-- Shilen