Assign Organisational Unit in User Account

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.)

Thus, ...

• when creating new user accounts, administrators always need to switch between different views in the software.
• when viewing/editing existing user accounts, administrators cannot find out to which org unit(s) it is assigned (or whther it's assigned to any org unit at all).

... all of which is more time-consuming than it would have to be.
Therefore, this feature request proposes to implement org unit assignment functionality from the side of the user account.
Apart from some structural differences, it tries to conceptualize this functionality as close as possible to role assignment.

2 Conceptual Summary

2.1 Creating New User Accounts

A pair of fields is added to the "System Information", called "Organisational Allocation".
It allows to assign one organisational unit with a respective position.

2.2 Editing Existing User Accounts

Opening an existing user account, an additional "Organisational Allocation" tab is offered.
It allows to add or remove assignments to org units:

3 User Interface Modifications

3.1 List of Affected Views

• Administration > User Management > User Accounts >  [user creation screen]
• Administration > User Management > User Accounts > [user account] > Organisational Allocation (new screen)

3.2 User Interface Details

3.2.1 Creating New User Accounts

• Field "Organisational Unit":
  A "Select" link opens a modal, offering the tree of org units with a radio button each, and a "Select" and a "Cancel" button.
  After selecting an org unit and clicking "Select", the modal closes and the user creation form displays the selected org unit.
  Besides, it still offers the "Select" link and a "Reset" link that erases the selection.
• Field "Position":
  A single-select menu offering all existing positions.
  The "Employee" position preselected (it cannot be deleted, so there will always be an entry) .

3.2.2 Editing Existing User Accounts

• On top, a system message is displayed in case there aren't any org units by now.
• Below, there is a table with "Organisational Unit" and "Position" columns
  • The table contains an entry for each tupel of org unit and position assigned to the edited user (i.e., users assigned to the same org units with different positions will have to distinct entries).
    In case the performing user has permission to view and read the org unit, its title is a link forwarding to the org unit.
  • Each entry is featuring a checkbox, and below the table, there is a "Remove Assignment" button available.
    Selecting a checkbox and clicking the button, a confirmation screen appears.
    Confirming it, the tab is displayed again, the removed entry is gone and the user isn't assigned to that org unit anymore.
  • Each entry is featuring an "Actions" menu in a column of the same name, offering two actions "Remove Assignment" and "Assign Position":
    Starting "Assign Position", an intermediate view allows to choose from all existing positions.
    • In case the org unit hasn't been assigned before at all, saving the intermediate view creates an assignment to the org unit.
    • In case the org unit has already been assigned, the position changes.
      In case the new tupel of org unit and position already exists for the edited user, saving the intermediate view is declined with an appropriate system message.
• Above the table, a filter is available featuring "Assigned Organisational Units" und "All Organisational Units" options (and an "Apply Filter" and "Reset Filter" button).
  • When opening the view, the "Assigned Organisational Units" option is preselected.
  • When returning from adding an assignment, the filter automatically changes to "Assigned Organisational Units".

3.3 New User Interface Concepts

(none)

3.4 Accessibility Implications

{ If the proposal contains potential accessibility issues that are neither covered by existing UI components nor clarified by guidelines, please list them here. For every potential issue please either propose a solution or write down a short risk assessment about potential fallout if there would be no solution for the issue. }

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}.