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.