Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

I've numbered items for reference.

"initial UI release, supporting Phase 1 functionality"

1 Support for displayName and displayExtension (#270)
2 Search by the name, extension, or displayName attributes of
 groups [S&B#1] (#336)
3 Search by the name, extension, or displayName attributes of
 namespaces [S&B#2] (#337)
4 Implement READ privilege (#338)
5 Implement VIEW privilege (#339)
6 Search by the name, extension, or displayName attributes of groups
 scoped to within a namespace subordinate to a given stem [S&B#7] (#340)
7 Search by the name, extension, or displayName attributes of
 namespaces scoped to within a namespaces subordinate to a given
 stem [S&B#8] (#341)
8 Improved Subject interface (#342)
9 has() (#334)
10 Improved schema validation (#267)
11 Delete groups that either have members or are members of other groups 
(#345)

# Grouper 0.6.x
12 Implement OPTIN privilege (#343)
13 Implement OPTOUT privilege (#344)

My priority from a UI perspective would be:

8, (1,2,3,6,7), 4,5,12,13,11,9,10

Comments in reverse order:

I'm not sure if 9 or 10 would have any impact on the UI at this stage - I 
think they are necessary once we support custom group types.

For 11 I have worked around this - but I need to check if I changed any 
Grouper code to do so.

If we don't have 12 and 13 I need to remove them from the UI for the time 
being.

We need to be able to search groups, but for a first release we can 
simplify things. I've attached what I currently have for simple and 
advanced searches (not actually implemented). We could decide to go with a 
simple search only. I currently only do a case insensitive substring search 
scoped by stem, and don't have any booleans. I would be happy to go with 
this for 0.6 and aim for more functional searching in 0.6.x when we will 
have custom group types to consider.

The Subject API is critical. For 0.6 it would simplify matters to have only 
two sources - one for people and one for groups. Having multiple sources 
for people would be doable so long as we don't need to search more than one 
at a time.

Regardless of whether we have one or more sources for people we need to 
agree how we get a subject from an authenticated user. In the current UI I 
use:
subj = 
Grouper.subjectType("person").getAdapter().getSubjectByDisplayId(null,remoteUser);

where remoteUser is my netId - isgwb. My subjectId is a number.

The current API has no equivalent to 'getSubjectByDisplayId'.

I don't really mind if the mapping is part of the Subject API or a separate 
pluggable interface - but we need a default to ship with Grouper -e.g. 
treat the netId as a subjectId.

public interface AuthenticatedUserIdAndSubjectIdResolver {
        public String getSubjectId(String authenticatedUserId);
        public String getAuthenticatedUserId(String subjectId);
}

public class DefaultAuthenticatedUserIdAndSubjectIdResolver implements 
AuthenticatedUserIdAndSubjectIdResolver{
        public String getSubjectId(String authenticatedUserId) {
                return authenticatedUserId;
        }

        public String getAuthenticatedUserId(String subjectId) {
                return subjectId;
        }
}


Finally, for now, I think we need to consider performance. I've found 
loading real groups with real people very slow - ~400 groups with 10000+ 
grouper_list values took longer that 6hrs. I need to look at this in more 
detail e.g. compare HSQLDB and Oracle, and look at memory usage - my loader 
eventually ran out of memory.

I don't think we need to solve all the performance issues for 0.6 but we 
need to set expectations in release notes. It would probably be useful to 
come up with a benchmark test we can run to create a set number (100+) of 
groups, memberships / privileges (1000's), including groups where the 
immediate memberships are groups.

Gary

----------------------
GW Brown, Information Systems and Computing

Attachment: simplesearch.png
Description: PNG image

Attachment: advsearch.png
Description: PNG image