Gary Brown: 2007-09-11: Searches are already case-insensitive substring searches. The advanced search screen does allow you to search against 'Any attribute'. The 'simple' search is configured through media.properties and you can choose to search (name OR extension) AND/OR (displayName OR displayExtension) - names include extensions.
It would be straightforward to introduce new configuration and code so that 'Any attribute' was searched by default and/or have a pair of radio options for Name / Any attribute with a site specified default.
Substring searches in SQL are not particularly efficient or scalable. It was suggested on a recent call that Lucene could be used with Hibernate to enable full text searching of relational databases. See http://blog.hibernate.org/Bloggers/Everyone/2006/12/20. I think this type of approach is best in the long term, however, it is likely to require significant effort to incorporate it in Grouper.

Jess @ Duke 2007-09-19: Our displayNames or display Extensions are quite long
e.g. Duke University:siss:courses:ECON:208S:01:2763:1180:students
is a Display Name and "students" is the Display Extension for that group. Perhaps we aren't taking the right approach to naming and that is part of our problem. But I could imagine typing in "ECON" to a search and hoping to jump to Duke University:siss:courses:ECON: with a result. Obviously searching for Display Extension in this case isn't going to do us any good.

Gary Brown: 2007-09-11: I agree that it would be good to have more control over whether or not certain Source Adapters are displayed / included in subject searches. SourceManager in the Subject API simply returns all known source adapters. I would prefer (and have suggested in the past) that sources.xml allow Source Adapters to be associated with one or more 'contexts'. Calling code would supply the appropriate context - which might itself come from application configuration files. In this case the two Source Adapters you mention are not actually configured through sources.xml, but are added by Grouper when it initializes. It would be good to have more control over the 'display name'  for  these adapters - the Group Source adapter ought to be useful.

Jess @ Duke 2007-09-19: Not sure if this is a UI issue or a backend issue or both, but I have difficulty with a generalized search on users – e.g. I can search for "Rob" in a search field that is just labeled "search" and return users who have "rob" in their names, have a unique identifier with "rob" in it, etc. It would be good to be able to choose what aspect of a user I'm searching for. Radio buttons for unique identifier, LastName, character match, etc.

Gary Brown: 2007-09-11: This ought to be straightforward, however, it may not be practical/desirable to display all groups - especially for your TA admins. How would you want to deal with users who have privileges for 1000's of groups?

Jess @ Duke: 2007-09-19: I can imagine, but am not sure it would necessarily be desirable, a boolean search for 'name' AND 'group' where I can type in a unique username or a Last name and also cross-search a group name at the same time. E.g. 'Carter AND ECON'.

Gary Brown: 2007-09-11: This would require enhancements to the Subject API, along with UI integration

Gary Brown: 2007-09-11: Sorting is now implemented, however, I chose an arbitrary limit of 200 beyond which lists are not sorted. This default can be changed, however, there are performance implications and you would need to experiment to see what is acceptable. The 1.2.1 API should cache subject attributes so sorting should be more efficient than with 1.2.0.

Gary Brown: 2007-09-11: It would be fairly straightforward to maintain a list of recently visited Groups and/or stems. You can currently 'save groups' for the current session. Saving favorites between sessions would come under C1 on Tom's list.

I have shied away from doing anything very clever with traversing the hierarchy - partly because you could end up with a very big tree to maintain, and partly for accessibility reasons. I'm open to specific proposals. I hope having favorites and improved searching would help 

Gary Brown: 2007-09-11: There are two places I can think of where this happens:

1. Editing group / stem
2. Showing stems where a subject has a selected Naming privilege
   For 1. the idea was not to encourage a user to go browsing whilst in the middle of an edit. I can't remember why I didn't make stem names links for 2, but I'm happy to make them links. Have you come across any other pages where stems are not links?

Gary Brown: 2007-09-11:  This raises the question of whether such a task would be better achieved through a script / loader...

There are a couple of ways your proposal could be implemented

1. Assigning access privileges to a stem could apply the same privilege to the same subject for all child groups of the stem.
2. Assign all the access privileges you require to one group and then pass the group to an appropriate method along with a stem. You may want the ability to replace any existing access privileges, rather than add to existing ones. This approach has the advantage of only having to enumerate the descendant groups once.

 This would probably make more sense to add as an API feature rather than implement it directly in the UI.

If there are a lot of groups it may well be a slow operation.

Gary Brown: 2007-09-11: STEM/CREATE privileges should be handled identically - do you mean Stem / Group privileges?

Jess @ Duke: 207-09-19: It might be ridiculous, but looking for STEM/CREATE prives in a different place from GROUP prives is confusing. If I want to grant someone STEM/CREATE it seems just another option within the same view as adding someone to a group.

 Gary Brown: 2007-09-11: I take the point on having a warning - I'll do something about it. Any 'undo' feature would have to be supported by the API.