Show Advanced KnowledgeHide Advanced Knowledge

Support of OrgUnits in Courses and Groups

1 Requirements

The management of users in courses and groups should support organisational units. This would be helpful especially in courses / groups to which users belong from different departments / faculties / teams. Support of the following use cases would be highly appreciated:

1. Admin / Tutor can filter course / group members to identify which users belong to a selected org unit .
2. Admin / Tutor can only see those course / group members in Member list that belong to the own org unit.
3. Admin / Tutor can only manage those course / group members in Member list that belong to the own org unit.
4. Admin / Tutor can access learning progress only for members of his/her org unit (e.g. Tutor from Dep. A sees just LP status of learners from Dep. A).

Scenery at DHBW:

DHBW wants to use Learning-Goals oriented courses (LOK) with a single course for students for differnt locations or different fields of studies. All participants shpuld be member of one course (/Group). The training and support for the students of a location (/field of study) is organized and performed by local persons ("tutors, Mentors etc). These tutors should not see personal data of other students

• to reduce their workload when searching for participants
• for data privacy/protection reasons (probably even must not see by law regulations)
• when gathering statistical data like "Time spent in course" or using surveys within courses (probably needs separate discussion)

To achieve this

• tutors etc can be members/superiors of orgunits or orgunit-subtrees (already part of the trunk)
• students are assigned to orgunits (manually or by userdefaults-plugin, probably orgunit import, currently already possible)
• at course/group-level there should be administrative settings (Like course/groupadmin is ou-aware and course-tutor ist ou-aware). When set, the respective role-holders should ony be presented those students with a matching ou-assignment.
• default for these settings should be not-aware so ILIAS behavior doesn't change in standard installations
• Placement of settings can be considered in the RBAC-tab of the object or in general object settings. Probably the settings should only be visible it ous are configured (e.g. at least one ou ist created)
• Least possible changes to ou, ou-generated roles or ohter components should be used. The re-use of the ou-superior-role and the "learning-progress-visible" setting can be considered on the ou-configuration side

If possible this behaviour could be inherited by relevant objects within the course. If this applies, there could be a need to differntiate between object-producers (authors, create, modify and see objects and object contents) and object consumers (tutors etc, see filtered settings of user's data).

Implementation proposal for ILIAS 5.2/5.3

Implementation for 5.2

New user data field "OrgUnits"

The new user data field "OrgUnits" is automatically update after assigning users to the orgunit role "Employee" and "Superior".
The user data field is shown non-editable in the following sections:

• Administration -> User -> Edit
• Administatrion -> User List (selectable columns)
• Administration -> User -> Settings -> Standard Fields
• Personal Desktop -> Personal Data
• Personal Desktop -> Personal Profile
• Local user administration (categories, org units)

The user data field is searchable in course, groups, test, survey, roles, ... and in the global user search.
The orgunit field can be exported in the profile export.

A cron job is implemented which performs an update of the assigned org units in the profile data.

OrgUnit filter in courses and groups

• The seperated tables for administrators, tutors, members and other course/group participants in tab 'Members' will be merged to one table with related filters.
• The new participant table offers an optional column for "Roles"
• The new participant table offers an optional column for "OrgUnits"
• Table filtering is offered for "OrgUnits" and course/group roles.
• An optional table column for OrgUnits is shown in the table for subscription requests and in the waiting list table.

2 Additional Information

• Idea / concept: Kunkel, Matthias [mkunkel],Jackisch, Ingo [jackisch]
• Interest in funding: DHBW
• Maintainer: Org Units - Martin Studer; course / group: Stefan Meyer
• closely related to Support of OrgUnits in Tests
• Implementation of the feature is done by (will be set by Jour Fixe / maintainer)
• Testcases by: (please add your name if you want to create the testcases for this feature)

3 Discussion

jackisch, Ingo [jackisch], 19 October 2015: The filtering as described in the requirement should consequently be applied to all elements in the course like learning data(progress) in learning objects, forum (postings), exercise (progress,responses) etc. Ideally, for the tutor/admin of one orgunit the course/Group would behave as if users from other orgunits were not members of the respective course/group.
With perspective to 5.2 and teh study programme element the same behaviour is needed

Kunkel, Matthias [mkunkel], Oct 19, 2015: Support of OU in courses and groups does not mean that all objects that can be added to a course or group are supporting OU as well. IMHO this has to be implemented for every single object type. Therefore, single feature wiki pages have to be set up for every object type (similar to Support of OrgUnits in Tests).

JourFixe, ILIAS [jourfixe], October 26, 2015: We discussed the request and possible implications and implementation. The concept needs to be clarified concerning the supported activities. Does "own org" unit mean "org unit in which I have a membership"? Is sending mails from the course part of this request? Is it allowed to add users from other org units? Are child objects affected automatically - or not? Is the waiting list org unit sensitive? Is ou-awareness related to role permissions? Please specify the concept by describing which activity needs which permission in the repository object _and_ in the org unit. Then set this topic on the agenda again.

JourFixe, ILIAS [jourfixe], August 01, 2016: We highly appreciate this feature suggestion and schedule it for 5.2.

• We still need to decide how we store the org unit assignments (title/text and path or ID and path) and ask Fabian Schmid (maintainer of OU) for feedback until the next Jour Fixe. This first implementation will not support an org unit filter within the learning progress of courses and groups.
• We define "Organisational Unit Assignment" as follows: All role assignments should be respected (not only "Employee" and "Superior")
• Selecting org unit in filter shall be done by selecting org unit in tree (and not as text).

Kiegel, Colin [kiegel] 2016-08-01: I have strong objections with this "OrgUnits" data field.

• multiple org-assignments are a reality in the scenarios which I have encountered so far. This leads to tricky questions like which separation character to use and what to do if this separation character appears in the OrgUnits title.
• Stefan Meyer explained today that this field will be updated in real-time and the cronjob will only update the field if something "went wrong". But this means that org-role assignments will be more expensive than today, because this field has to be updated in real-time. Dealing with multiple org-assignments will make this update-process complicated.
• the whole approach feels very weird, because we don't do anything like this yet. Imagine for example a user-data field which lists all course memberships of a user (+ cronjob to be on the save side). I really wonder, what's next to come if we proceed along this road?

I understand that the "OrgUnits" data field aims at improving performance (e.g. text-based search or listings).

I hope we can agree, that what we want to do here is some sort of caching mechanism (roughly speaking) - i.e. storing derived information redundantly, because the derivation process is costly. After all the user-data field is supposed to be "read-only".

The questions are

• do we cache the right thing?
• do we cache it the right way?

I have doubts about both questions and would like to discuss alternatives.

The what: IMO getting the OrgUnit-IDs of a user is not very expensive. Because ILIAS probably needs the user data anyway one JOIN would do it without additional round-trips to the database (i.e. same amount of queries as before). What might indeed be expensive is to create a textual representation of the path to these org-units, because this probably means walking the whole org-unit tree (which could be deep). If this is the pain-point I suggest to cache this relation instead org-id <-> textual path representation. Note the difference of org-id instead of usr-id.

The how: What about either a dedicated database table for this (which can be joined) or using the globalcache-framework for this? After all globalcache tries to solve exactly these kind of problems IMO. Of course globalcache needs to be configured and activated per installation - but this is a different story. I think the long-term strategy should be to use globalcache for problems like this. If globalcache doesn't fit, it should be extended (or coplemented by a new XYZcache service). I am by ways no caching expert, but it feels wrong to use userdata fields for caching purposes. This feels like a quick-and-dirty-solution (no offense intended) - is this our caching strategy we want to have in other places, too? Really?

MBecker 2016-08-02 
I know I know... haters gonna hate and Colin will be less than pleased to read me preaching this litany again, but I have to speak out that every single case of multiple org unit assignments I came across so far was a heuristic for a (most likeable, understandable, brought-from-the-frontlines-of-pragmatic-projectmanagement artifact but still) defective modelling of the tree.

Most popular among those errors:

• mixing superior/employer relations with job-responsibilties (e.g. person requires acces to a foreign unit to be able to do their work)
• incorrect consideration what an organizational unit is representing (e.g. legal constructions do not match actual hierarchies, think "a BENELUX department consisting of three companies while the actual hierarchy has the superior for the other two located in the Luxembourg-company").

Once you boil it down, you have to consider what questions you want to ask the tree and if it is more than one -  "Who is jedi of/disciple of" vs. "Who needs access where" vs. "How many cones of ice cream do we need?" - you are entering a warm place called concept-hell.

BTW, my answer to this dilemma are multiple trees. (Which I don't have, sorry.) But for your own mental safety I recommend to try at all cost to not support multiple org unit assignments.

Schmid, Fabian [fschmid], Response to JF, August 01, 2016:

We still need to decide how we store the org unit assignments (title/text and path or ID and path) and ask Fabian Schmid (maintainer of OU) for feedback until the next Jour Fixe. This first implementation will not support an org unit filter within the learning progress of courses and groups.
As colin mentions already, this is a sort of caching because real-time generation of those information is a huge impact on the database due to recursive requests to the database. A way to handle those expensive requests is to store them flat. there are of course a lot of ways to do this, two of them are emntioned above:

• store the text representation of a orgu-path in the usr_data table for each user
• store store the text representation of a orgu-path in a dedicated table

every storage of redundant data (both of those suggestions store redundant data) needs a mechanism to update and verify the stored information which is suggested to be done with a cronjob (which is in fact not a new strategy in ILIAS or a precedence-case, thinking about Disk-Quota, Checking Weblinks or Object Statistics... All of those coulbbe rendered in real-time, but would be to expensive). In this case the cron-job is a backup-strategy if something when wrong during real-time generation which will not lead to "lead to subtle unexpected behaviour" but in more consistent data.

As colin says: I hope we can agree, that what we want to do here is some sort of caching mechanism (roughly speaking) - i.e. storing derived information redundantly, because the derivation process is costly. After all the user-data field is supposed to be "read-only". This is perfectly true.

For the decision which wax to go for storing the redudant data, the following decision made by jour fixe is important:

We define "Organisational Unit Assignment" as follows: All role assignments should be respected (not only "Employee" and "Superior")

Fortunately then the assignement of a user to the org-units can be found more easily and performant since we just can join and don't need to find the matching roles using CONCAT which is tragically slow. In that case (and for ILIAS in general) we would liketo introduce a new role_type which can be set by any object which creates local roles.
But with this definition of Organisational Unit Assignment as written above, joining a table with the text-representations of Orgu-pathes will be easy.

Selecting org unit in filter shall be done by selecting org unit in tree (and not as text).
We will discuss this point with leifos which chanrged us with the implementaion of this. Especially because "This first implementation will not support an org unit filter within the learning progress of courses and groups." says there won't be filtering in the first version.


Response to Kiegel, Colin [kiegel] 2016-08-01
I hope the answer above matchs most of your questions.

As already said, this is a caching mechanism.
The what
This seems to be the better solution. 
A path will be represented as "Orguname One > Orguname Two > Assigned Orguname"

The how
This would lead to a flat table  with "org-id <-> textual path representation" which easily can be joined. this tables will be populated on changing/creating orgunits and with a CrobJob.

using the globalcache-framework for this
This would be the wrong way since GlobalCache is a key/value-storage and populating this woulb be expensive.

Answer to MBecker 2016-08-02
Please, do not be angry with me, but Multiple OrgUnits per User is not the topic of this feature wiki entry and is already possible.

JourFixe, ILIAS [jourfixe], August 15, 2016. We highly appreciate Fabian's suggestion. A dedicated table should offer text representations of org unit assignments for performance improvment.

4 Implementation

New "combined" table for all course/group participants with role assignment and OrgUnits as selectable columns.

New search field for User Search in courses, groups, exercises, tests, roles, ...

Test Cases

Test cases for the re-vamp of the Participant list in course were completed at 2016-08-26

• 5645: Ansicht des Mitgliederreiters ändern
• 5647: Mitglied direkt hinzufügen
• 5651: Benutzer suchen und als Mitglied hinzufügen
• 5655: Einzelnes Mitglied bearbeiten
• 5656: Mehrere Mitglieder bearbeiten

Test cases for the re-vamp of the User standard fields in course were completed at 2016-08-26

• 13037: Standardfelder für Benutzerkonten einstellen
• 13041: Beitretenformular mit Organisationeinheiten

Approval

Approved at August 26, 2016 by Kunkel, Matthias [mkunkel]