Search Loop for User Accounts

1 Initial Problem

By now (v8), the results of a user search in different object types (courses, groups, roles a.s.o.) cannot be refined by additional criteria.
Once you received a list of hits, you can only assign this subset of users or start a new search.

In the case of different user account data fields, this isn't any problem as you can user several of them parallelly.
However, it is not possible to search for, e.g., specific user account data and an assigned role, an organizational unit a.s.o.

2 Conceptual Summary

We suggest to allow a refinement of search results:

• Instead of simply accepting the received subset or to start an entirely new search, there is an option to start a new search based on the present results.
• Starting this option, again the list of search criteria is presented.
  New search criteria are combined with the precedent ones in an AND logic.
  This way, a "loop" takes place which may be continued in any results view.
  Once the search process is aborted (explicitly or by leaving the current view), the stacked search criteria are dismissed.
• While choosing (more) search criteria, instead of radio buttons ("Search for users", "Search for Roles" etc.) the form offers checkboxes (so multiple criteria can be selected).
  Whenever opening "Refine Search", all criteria are displayed that have been selected and not been unselected up to date.

3 User Interface Modifications

3.1 List of Affected Views

• Results view of user search
• List of search criteriain user search

3.2 User Interface Details

• The search results view is enhanced by a "Refine Search" button.
• Clicking it, a modal opens that shows the list of search criteria again, with the ones chosen before.
• The form offers checkboxes, so it is possible to use more than one search criterion type in parallel.

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

(none)

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