User / group management

[AFaust]

FEATURE / ENHANCEMENT

Alfresco by default only provides user / group management capabilities as part of the Alfresco Share application. If a customer does not intend to use Share and instead opt for either a 3rd party or ADF-based client, they would still have to use Share for any user / group management, or develop the capability in their own client using the public ReST API (with its various limitations).
A basic user / group management capability should be an integral part of an administration UI, and barring any (known) plans of Alfresco to develop such capability on the Repository-tier administration console, we should look to add this to fill the gap, and allow greater flexibility in how Alfresco is deployed and used by customers / community members.

[AFaust]

Since user / group management is not a trivial tooling, before I go ahead implementing it I will outline some design / functionality ideas which might warrant feedback and refinement.

Premises

Separate tool pages would be created for user and group management. Both pages would support two dstinct display modes (search + details) depending on URL used to access them. Reason for having single pages (web scripts) with multiple modes each is that Admin Console constructs / groups navigation based on web script, so having pages for each mode itself would create multiple entries in the navigation, and the secondary mode (details) would not support being called with an unparameterised URL from the navigation.

Surf Extension Modules (yes, those are a thing on Repository-tier too) should be supported to allow for simple extension of details view and details edit HTML structures, using FTL markup directives around individual fields as well as groups of fields. The default admin page template should be adapted to support use of FTL markup directives to allow custom JS / CSS files to be included via extensions, e.g. on-change validation handlers for any custom fields. Extension Modules should also be supported with regards to action buttons provided in detail pages.

Any querying / searching for users / groups should exclusively use DB-bound queries, so either canned queries or TMQ FTS/CMIS. Search result listings as well as any navigation of child elements should always support sorting on primary result properties and pagination using at least simple offset-based pagination - idealy semantic offset pagination should be supported, e.g. retrieving results not over the global result set but from sub-blocks based on e.g. name prefixes (might require multiple, incremental query executions until result set is filled and value range - min/max characters - to be determined via some on-start lookup, caching and behaviour based invalidation/update).

User Management

• user search should support dedicated first name / last name / user name query fields
• user search should support optional filters on one or more authority zones (default: no filtering)
• user search should support offset-based pagination and sorting on at least first, last and user name
• user search would provide actions to delete user, enable/disable or open details from search result
• user search would provide action to create new user (in the default authority zone)
• details page would provide actions to delete/edit user details (via dialog), set password, and grant/revoke licenses (if on Enterprise)
• details page would include (read-only) view of parent / containing groups with links to respsective details page
• details page would not provide means to manage group containments of user (sole purview of groups management)

Groups Management

• group search should support dedicated authority / dispaly name query fields
• group search should support optional filters on one or more authority zones (default: no filtering)
• group search would provide actions to delete group, open group details or create new group
• details page should provide separate sections for group detail properites, group parents (read-only with link to respective details page) and group members (search functionality consistent with generic group search)
• group member section in details page would provide additional "remove" action to remove member from current group
• group member section in details page would provide two actions to add members via popup dialogs with dedicated user or group search + result list elements (search consistent with generic user / group search functionality, though without actions other than "add")

[AFaust]

@binduwavell / @yregaieg It was too late to start on this big idea during the hackathon after working on the smaller items, so I just collected my thoughts / ideas about how to structure this tool. Of course it sort of has to be similar to what people know from Share, but also would need to be a bit simpler in terms of how much could reasonably be done on one page without a more fleshed out UI framework to help with complex widgets. If you guys have a chance to look over and give feedback, it would be appreciated.