...
- Support for more than 2 (HSQL and Oracle) RDMB platforms
- Support for intersections, unions, etc.
- A lack of longer-term use to discover performance issues and ongoing maintenance efficiencies that might be gained
- There is also no grouper UI yet, but I think most of us are used to handling group management via command line at this point
See Comparing the uPortal Groups Service and Grouper for a further comparison.
Grouper-GAP Collaboration
A minimalist appoach
...
- uPortal groups switch to a slightly different group name format. Instead of <group service>.<group id> we would follow Grouper heirarchy and naming conventions. This could be handled directly or via an interface for those in the process of conversion. Legacy channels are also reliant on the uP group naming conventions, so they would need an update if the portal code didn't act as a filter. To do so would require a uP -> Grouper mapping. I wonder if this would be a problem across other kinds of applications that use groups (eg. Confluence and JIRA) so that a grouper-provided mapping facility might be useful?
- How to handle expected, uPortal specific groups (i.e. portal administrators)? If Grouper was the centralized groups service for a campus, then it means that either uPortal would need to have the groups on which it relies extracted from code and specified in some parameterized way, or uPortal would need to create groups via the Grouper API upon installation.
- A loader to move uPortal groups from the uP data store into grouper would be very useful