Grouper UI Functionality Requests
Duke has been using Grouper extensively to manage course-related and other groups associated with applications such as iTunes U, Lectopia, etc. This semester, for the first time, we created course space in iTunes U for 4000 courses. This required extensive use of the Grouper UI to manage the groups associated with these courses. During this process, we encountered some difficulties with the navigability of the Grouper UI along with some capability limitations of the interface. This document addresses some of those issues and provides some feedback for what we would ideally like to see changed in the application.
Group Search Capability
Currently, the group search page allows searching based on the value for the name of a group, display name of a group, extension of a group, or display extension of a group. We would like to be able to put only part of each of those values, in other words, a substring search. What would be most useful is to be able to search on a substring of a value for any attribute of a group, including description, and any custom attribute that someone might add to a group. For instance, if the name of a group for a particular course includes "ECON", we'd like to be able to search based on this substring and return a list of all groups which contain "ECON".
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.
The Group Source Adapter and Internal Source Adapter search options are meaningless to most users. It would be nice if we could hide those to avoid confusion.
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.
Individual Search Capability
We would like to be able to search for an individual, and be able to list what privileges the person has to all groups for which they have privileges. Currently, this can be displayed from each individual group, but not from an individual.
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'.
Currently, if we wanted to search for someone with a NetID such as "joe", the search would return everyone with Joe as part of their name. We need the ability to add more named searches so that we can define searches for specific attributes for an individual.
Gary Brown: 2007-09-11: This would require enhancements to the Subject API, along with UI integration
Currently, when browsing groups, there is no way to alphabetize or otherwise sort the list. Once the list of groups grows large, this can be cumbersome for finding the desired group. The ability to sort lists would help a great deal.
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.
Also, a lot of time is spent navigating to the place where you want to be. If there were a way to save the place one has navigated to so it can be easily returned to, or if there were a way to do a tree view of some sort, that would be beneficial. Perhaps a favorites or recently-modified list would help. More to the point, an easier way of traversing the hierarchy would improve things a great deal.
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
On stems, some of the stem names in the interface are hyperlinks and others aren't, even when the text is identical. Ideally, these would be consistent. The hyperlinks are useful.
Gary Brown: 2007-09-11: There are two places I can think of where this happens:
- Editing group / stem
- 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?
It would be nice to have the ability to make certain changes to groups for an entire branch, so that the command does not need to be repeated a large number of times. For instance, granting administrative authority to groups currently can be a long process. If there were an option to change permissions for an entire branch of groups, this process would be much faster. This would be optional - there may be times when granting privileges recursively would not be appropriate.
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
- Assigning access privileges to a stem could apply the same privilege to the same subject for all child groups of the stem.
- 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.
There is currently some inconsistency about how privileges are granted. The way STEM privileges are granted looks very different from the way CREATE privileges are granted. It would be nice if STEMs could be treated in the same way that CREATEs are handled.
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.
Currently, it is very easy to delete things with no warning or validation beforehand. Someone could delete a stem and have no idea what they just did. This makes it less appealing to grant privileges to anyone but the "power users." Some sort of warning/validation for deletes would be good. Also, if it were possible to have an undo action, that would be ideal.
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.