-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User / group management #161
Comments
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. PremisesSeparate 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
Groups Management
|
@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. |
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.
The text was updated successfully, but these errors were encountered: