Assign Users From a Text File

1 Initial Problem

A list of the employees who are to attend a specific course arises in an "other" system than ILIAS (e.g., an HRM tool).
Those users are now to be assigned to the course.
Such a list may contain ...

• any number of names
• users who don't have any common characteristic within ILIAS
• persons who don't have an ILIAS user account

In the worst case (and, presumably, not too rarely), the course administrator will have to search for user accounts by many different criteria which is very time-consuming.

Therefore, this article suggests to add another option in the user search, i.e., to upload a text file with usernames which is then processed by the system.
In every view where the user search can be started, such an option should be available.

2 Conceptual Summary

2.1 2.1 File Format and Processing

The accepted file format is .txt in UTF-8 character set; a byline must indicate this accordingly.

The usernames are evaluated per line.
Rows in which no unambiguous username can be identified, are ignored.

The following applies to checking user names:

• No case sensitivity - there is no check for upper and lower case letters. Llearner, llearner, LLEARNER will be matched if the original username is llearner (and vice versa).
• Spaces are ignored.

2.2 Workflow

After clicking "Search User", an additional option "From File (username)" is offered (e.g., at the end of the list).
After selecting it, a file picker appears.

The usual warning message appears in case ...

• the "Search" button is clicked without uploading a file before
• a wrong file format is uploaded

After clicking "Search", the results list is displayed, featuring all identified user accounts.
The results list behaves in the same way as with other search options:

• There, one or all of the result can be selected and assigned, if necessary by specifying a role (in training courses, groups, etc.).
• The number of rows can be adjusted.
• The columns can be sorted.
• More columns can be displayed, according to the "Administration > User Management > Settings > Standard Fields > Searchable" setting.

2.3 2.3 Privacy

The results must not contain any user accounts that the executing user cannot find for certain reasons (TimeLimitOwner, positions, ...).

3 User Interface Modifications

3.1 List of Affected Views

The immediate purpose of this article aims to

• Tab "Members" within courses

The immediate purpose of this article aims to

• Tab "Members" within courses

... however, the search option could be useful in any view with a "Search Users" button:

• Tab "Members" within groups
• Tab "User Assignment" within roles
• Tab "Staff" within organisational units
• Tab "Members" within individual assessments
• Tab "Submissions and Grades" within exercises
• Tab "Participants" within tests with limited participants
• Tab "Moderators" within forums
• Tab "Contributors" within blogs
• Tab "Appraisees" within "360° feedback" surveys
• Tab "Assigned Users" within competence profiles

3.2 User Interface Details

• Radio button "From File (username)"
• File picker

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

There aren't any additional personal data to be stored or processed to implement this feature. For other privacy implications, s. chaper 2.3.

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.

• …

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