Multi-action Add to Organisational Unit in User Management

1 Initial Problem

By now (v8), user accounts can only be assigned to organisational units from one side, i.e., the org units.
(E.g., roles can be assigned from both sides: Assign roles to users, or assign users to roles.)

In a first step, we proposed Assign Organisational Unit in User Account which allows to assign single users to org units when creating or editing them.
However, in comparison to assignment of roles, this approach still lacks a way to assign several users at once.
Therefore, this feature request proposes to implement a bulk assignment functionality from the list of user accounts.

2 Conceptual Summary

In "Administration > User Management > User Accounts", an additional bulk action is introduced that allows to handle all selected user accounts in terms of org unit assignment (with one org unit and position at a time).

3 User Interface Modifications

3.1 List of Affected Views

• Administration > User Management > User Accounts

3.2 User Interface Details

• The menu on top and bottom of the table offers an option "Assign Organisational Unit" (before "Delete").
  • In case the option is executed without any user account selected, a system message appears pointing out that no selection has been made.
• Once user accounts have been selected by their checkboxes and this option is executed, an intermediate view appears offering ...
  • a single-select menu with all existing positions (and the "Employee" position preselected ... it cannot be deleted, so there will always be an entry).
  • the tree of org units with a radio button each, and a "Confirm" and "Cancel" button.
• In case an org unit has been selected, clicking the "Confirm" button will forward the performing user back to the list of users with an according success message.
  • In case no selection has been made, the intermediate view appears again, showing an appropriate system message pointing out that no selection has been made.

3.3 New User Interface Concepts

(none)

3.4 Accessibility Implications

(none)

4 Technical Information

{ The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }

5 Privacy

(no additional personal data has to be stored or processed)

6 Security

{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }

7 Contact

• Author of the Request: Suittenpointner, Florian [suittenpointner]
• Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• CaT Concepts and Training GmbH

9 Discussion

10 Implementation

{ The maintainer has to give a description of the final implementation and add screenshots if possible. }

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.