Change of Behaviour for Copying Linked Objects Within Containers

1 Initial Problem

When a course (or group or folder or category) is copied, all objects that are contained within it are cloned. That means that a new object is created. For linked objects wihtin containers that are being copied that same behaviour applies: the linked object is copied and the copy links to the same target as the original.

This behaviour is very useful and totally logical if the target of the link lies outside of the copied container. Just imagine a "support" learning module that is linked from a general support area into the category substructures of some departments. When such a departmental structure is bein copied, the link to the learning module should still point to the original learning module in the general support area.

Now imagine a course with a q&a forum on its top level and with 30 tutorial groups into which the same forum is linked (reason: students are very likely to spend most time in the subgroup, butalso some time in the main course, so you want to have the forum be present in both contexts). When this course is copied, the copy will contain 30 groups with (links to)  forums in it that point to the old course. This is a common usecase in term-based educational institutions like universities where the same course (structires) are being copied form one semester to the next). The current behaviour however does not make sense and produces great lot of manual cleanup work in each of the groups in order to re-use the course.

The example course at the University of Freiburg where this problem occurs every term is called "Wissenschaftliches Denken und Handeln in der Medizin" and each group comprises a forum and 6 linked tests.

2 Conceptual Summary

We propose to handle copying linked objects just like "internal links" on page editor pages of container objects and learning modules are treated.
If the two representations of a linked object (i.e. the target and the source) are child objects (of whatever depth) of the same container, on copying the container, the realtion should be reestablished.

This means that links (linked objects) within the same substructure should be preservered when they are being copied along with the container. After the copying process, targets of linked objects should NOT point point to outside of the copied parent structure when the originals did not point to outside the their parent structure.

Example:
In the above example this means that when the course is copied...

• the cloning function marks the course as the "temporary root" node for the copying process
• the cloning function checks the entire subtree of the course for linked objects and identifies links within the subtree
• the forum in the course is identified as a "source" object for links deeper in the course's structure by teh cloning function
  • just like now, the forum should be copied
• when the groups are copied, the cloning function recognises that there where linked objects (a forum) in the original groups with a target within the subtree of the " temporary root"
  • new behaviour: a linked object is created pointing to its new copied source (the forum on the course level in the course copy)

3 User Interface Modifications

3.1 List of Affected Views

none

3.2 User Interface Details

none

3.3 New User Interface Concepts

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 Information

{ Please list all personal data that will need to be stored or processed to implement this feature. For each date give a short explanation why it is necessary to use that date. }

6 Security Implications

{ 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: Glaubitz, Marko [mglaubitz]
• 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.

• Universität Freiburg

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