User properties as object precondition

1 Initial Problem

Some installations with language-specific content suffer from a cluttered repository if they target many languages.

The reason behind this are certain content objects which cannot be translated. While builtin ILIAS learning modules offer great translation options, the same is not true for state-of-the-art SCORM authoring tools. This often leads to repositories which offer different language-versions of the same object to the user - multiplying the object-count by the number of languages. The user needs to pick the right version himself.

2 Conceptual Summary

The existing object preconditions are extended by a new type "user language"

Modal for new Preconditions

After clicking on "new preconditions", ILIAS opens a modal of type "Interruptive Item" including a two-step sequence of forms, like example 2 "Show form in modal" of Type "Roundtrip Modal".

Repository Object Preconditions

Existing Workflow

If "Repository Object" was selected, the User is asked the already existing sequence of questions, but still in the modal instead of new pages - as follows

Step 2

(Form Buttons)
Next Back

Step 3

User Property Preconditions

New Workflow

If "User Property" was selected, the User is asked a new sequence of questions (still in the modal) - as follows

Step 2

(Form)
Please select the User Property you want to define as precondition
User Property: (DROPDOWN with the following options)

• Language
• Country
• nice-to-have: all user profile fields

(Form Buttons)
Next Back

Step 3

(Form)
Precondition via: User Property "{Selected User Property}"
Precondition for: {Name of repository object}
Condition: [Dropdown]

• is equal
• contains (*)
• starts with (*)
• ends with (*)
• is not equal
• does not contain (*)
• does not start with (*)
• does not end with (*)

(*) Conditions marked with a star are only shown if the selected User Property is "free text" as opposed to a selection list.

Reference Value:

• [Dropdown] (if the User Property is a selection list like "language" or "country")
• [Free Text Input field] (if the User Property itself is free text)

(Form Buttons)
Save Back

3 User Interface Modifications

3.1 List of Affected Views

• Create New Preconditions
• List of Preconditions

3.2 User Interface Details

Create New Preconditions

See "conceptual summary" for details

List of Preconditions

3.3 New User Interface Concepts

-

3.4 Accessibility Implications

-

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

Users with control of preconditions and access to the "permission tab" of at least 1 object can test existing user accounts for their properties via "who has which permissions". Therefore set up a precondition like "property X equals Y" and see if User Z has still permission to the object.

However the function "who has which permissions" already shows very private information with regard to the listing of assigned roles for a given user account. It also shows if users can access higher levels of the repository hierarchy (often indicating if users are part of certain organisational units or members of groups/courses). Therefore the core-concept of the "who has which permissions" feature is solely responsible for this privacy-issue in general. It must be treated as "implicitly quite verbose" wrt to private data already. 

Access to the permissions-tab is only granted in very few situations with the default configuration of ILIAS. Even object owners can't access permissions, unless they have very certain roles like

• course administrator
• group administrator
• or systemadministrator

These roles usually can access private data already in other ways (add user > search, etc.).

To address this, there would be two options

1. the "who has which permissions" could be restricted to users with certain global roles.
2. preconditions could be limited to those user data fields which are marked as "searchable". The searchable-setting needs to be introduced for the language user property. However removing the "searchable"-setting from a user property could then have huge impact on existing preconditions. 

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: Kiegel, Colin [kiegel]
• Maintainer: Meyer, Stefan [smeyer]
• 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.

• item Industrietechnik GmbH

9 Discussion

A related feature was suggested for ILIAS 9: Use user profile field match as precondition. Maybe the two features con be combined

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