Admin User/Group/Role Portlet enhancements

• Key: JS2-241
• Type: Improvement
• Status: Open
• Priority: Major
• Assignee: Ate Douma
• Reporter: Ate Douma
• Component/s: Admin Portlets
• Affects Version/s: 2.1-dev, 2.1
• Fix Version/s: 2.2.2

Description

To be able to use the Admin User/Group/Role portlets for a medium to large (> 10.000) number of users, together with strong security requirements, the following enhancements are envisioned:

Configuration of User Details Portlet contents and behavior:
- allow form based entry of a configurable set of User Attributes
  on a new User Details Portlet tab (User tab)
- specify which tabs are visible (e.g. hide Attributes tab)
- specify default values for role and profile rule for new users (including none)
- specify if default role and/or profile fields should be shown on "Add User" form
- optional display Password tab contents on (new) User tab, allowing Password tab to
  be hidden

Further enhancements to the User Attributes entry Form:
- order and position of each field (row, column)
- i18n labels
- field type: text, boolean (checkbox), list, data (calendar)
- field validation: max length, range, date checks, required (update to null)

Implement enabled property of Principals (User, Role and Group):
- see JS2-151, task 9)

Filter/query enhancements to the User Browser (and User Chooser for Role and Group assignments):
- filter on User Attributes
- filter on PasswordCredential enabled property
- filter for role/group assignment poplists (possibly with client side javascript)
- Preferences based configuration for:
  - filter options (which User Attributes can be used in filtering)
  - display resultset options (which User Attributes are shown)

Filter/query and resultset enhancements for the User/Group/Role Browsers and Choosers:
- (optionally) do not auto query
- filter on enabled property (see above)
- resultset page navigator controls (<<, <, >, >>)
- Preferences based configuration for:
  - table window size (number of records displayed)
  - max number of records retrieved
    (retrieving more than say 100 records isn't useful and very memory and time consuming)

Role security restrictions for certain operations:
- differentiate between create/remove/update and assignment tasks
  In some organizations, assignments can be handled by non-administration personnel

Comments

[Ate Douma]

Implement enabled property of Principals (User, Role and Group): JS2-151, task 9)

[Ate Douma]

The JS2-251, task 9) now will be implemented through JS2-27, together with JS2-21 to be able to get it into the 2.0-FINAL release.

[Ate Douma]

Wrong issue JS2-251 mentioned above. That should read: JS2-151 of course.

Michael,

I don't know why you think this issue will be or should be fixed for 2.0-FINAL, but I won't be able to do so.
So I'm gonna push this back again to 2.0-POST.
If someone really wants these features (besides those already implemented or which will be implemented through JS2-21 and JS2-27) done for 2.0-FINAL
then please take over this issue or provide a complete patch...

[Michael Lipp]

Ate,

I just noticed myself when going through the JIRA notifications. I did a bulk change, moving all issues with fix version 2.0-M4 to 2.0-FINAL. And this issue had *both* 2.0-M4 and 2.0-POST and thus matched the filter.

[Ate Douma]

Resolution will take too much time to make it for the 2.1 release

[Ate Douma]

Moving to 2.3
The latest changes to the security model will make it much easier to implement these, but we'll not be able to do that before the 2.2 release

[David Sean Taylor]

out of scope for 2.2.1