...
Release | Tentative date or time frame |
1.6 | |
2.0 | |
2.1 | |
2.2 | 2014Q2 2014Q1 |
Release | Item | Description |
---|---|---|
2.2 | Grouper has an administrative UI, the Membership Update Web UI, and as of v2.0, additional Web UIs for attribute, role, permission, and user invitation management. Further, several substantial UIs have been created by Grouper users, usually designed to meet needs in a specifically identified context. This roadmap item is aimed at addressing how Grouper should engage, support, or borrow from these efforts to provide UI capabilities that are closer to contextual needs more often than at present. | |
2.2 | Services in Grouper | Add ability to tag objects in Grouper (via the new attribute framework) so that folders, groups, permissions can be grouped into a "service". The API/UI/WS could filter search results based on the service to make it easier for users to perform tasks in Grouper. See planning page. |
2.2 | Improved Grouper configuration | In order to make Grouper more easily deployable across environments, and more easily upgradable, add ability for cascaded config files, and expression language in config file entries. There can be a default configuration file, and an override file so that only the changes from the default can be tracked in the overlay. See Grouper configuration overlay. |
2.2 | Provide group, membership, and group management role information via SCIM, in partnership with SURFnet. | |
2.2 | Treat privileges as Group lists | Remove the pluggability of Grouper privileges (Group READ/UPDATE etc), treat them as group lists to improve WS operations, simplify the UI, etc |
2.2 | Unix GID management | Built-in support for managing unix GIDs by assigning a numeric ID to each group and folder. |
2.2 | Migrate from legacy attributes to the new attribute framework in a transparent way. The old API and WS and UI should still work correctly. Plan to migrate lists and hooks as well. | |
2.2 | COmanage integration | Work cooperatively with the COmanage project to integrate Grouper within COmanage. Integer group ID's, WS operation tweaks |
2.2 | Grouper user data | Store information about a user in grouper in a generic way. e.g. recently used objects. favorites, etc. |
On-going | Grouper Core enhancement | Continue adding capabilities to meet requirements from the field. |
On-going | Community contributions | Solicit and publicize community contributions of extensions and complements to Grouper. |
Not yet assigned | Security plugins | Spring security, Shiro, .NET plugins for Grouper WS that might be able to be distributed with the plugin itself. Initial proof-of-concept code available: https://spaces.at.internet2.edu/display/Grouper/Unicon+Grouper+Contributions. |
Not yet assigned | Access Management Standard WS API | Similar to the CIFER effort, develop a standard WS API |
Not yet assigned | Further KIM-Grouper integration | Work cooperatively within the CIFER project to refine the Kuali KIM services interfaces and extend existing integration beyond group-level into roles & permissions. |
Not yet assigned | More WS operations | Add ability to manage attribute and permission definitions 100% via the WS. Currently many things can be done via the WS but not all. Currently the gaps can be addressed via the UI/API. |
Not yet assigned | Register for notifications | Add ability for users to register to be notified of changes to specified objects. |
Not yet assigned | Further uPortal-Grouper integration | Complete Phase II deliverables. Time frame for Phase III deliverables still to be determined in concert with uPortal team. |
Not yet assigned | More provisioning connectors | Add further connectors to reflect specified group, membership, role, and permission information into external systems and services. |
Not yet assigned | Scaling REST webservice | An page in the Administration guide, Grouper always available web services and client, demonstrates one way to provide always available services using a specialized client. The CIFER REST web service will need the server-side capability to provide that always-available functionality. In addition the REST API should be able to access multiple, read-only caches so it can efficiently handle any increase in query requests, most of which will not need to directly access the primary database. |
Not yet assigned | Namespace Uniqueness Constraint | Active Directory has some constraints regarding the storing of group and membership objects of the same name. This item would create an optional API-level constraint which would prevent you from re-using a name across multiple objects (stem, group, attribute, etc). |
...