...
- 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