Managing the Exportfiles via IRSS

This Feature-Request is part of the larger strategy to move all user-uploaded files to the ILIAS Resource Storage Service: consult ILIAS Resource Storage Service (Project). Feature requests like this are spin-offs from IRSS: General Overview of Components to Migrate (ongoing) and are basically already approved, we just like to keep track of these.

1 Initial Problem

The export files are user generated files. They are currently not part of the ILIAS Resource Storage Service, and are not stored centrally. In Courses for example the exports can be found in courses/xml.

This makes it harder than it needs to be to implement features like a installation-wide clean-up of unused export files, or OER-Harvester automatically creates Exports.

2 Conceptual Summary

The component-specific storage places are to be replaced by storage in the IRSS. Note that this only affects exports of type XML, and not e.g. HTML or QTI.

3 User Interface Modifications

3.1 List of Affected Views

-

3.2 User Interface Details

No changes to UI.

3.3 New User Interface Concepts

No changes to UI.

3.4 Accessibility Implications

No foreseeable accessibility implications.

4 Technical Information

A migration will be provided with which all existing export files of type XML are moved to the IRSS. No component-specific implementation from other maintainers will be necessary. Components which also offer other export types (HTML, QTI, etc.) have to migrate them separately.

Unmigrated export files will still be displayed and made available for download in the Export GUI, but they are ignored in the export configuration of Containers (omit, reuse, create new).

Leftover export files from broken, deleted or otherwise unavailable objects will not be migrated.

5 Privacy

Data will be stored centrally in the IRSS, and not in component-specific directories.

6 Security

Since export files are to be stored centrally by the IRSS, and not in different places on a component basis, we expect security to improve.

7 Contact

• Author of the Request: Meyer, Stefan [smeyer]
• 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.

• …

9 Discussion

Schmid, Fabian [fschmid] 2024-05-06: I am very pleased that the topic of IRSS and export files for ILIAS 10 is being addressed and I am very happy to think along and help if I can. The export files are one of the main sources for directories in the ILIAS file system, as so far each component has created its own directories for exports. With the replacement of these directories, we are coming a good deal closer to the end of legacy file use.

I have had a few thoughts about exports in the IRSS, which I would like to make available here. as the feature request is still quite vague, I don't know whether these considerations have perhaps already been taken into account.

from the point of view of the IRSS, there are different ways of saving and managing the export files. in most cases, exports are ZIP files, in other cases they are Excel or CSV files, for example, and more rarely special formats such as QTI (although these are also zipped).

if exports were always ZIP files - and if you want to stick to the existing mechanisms and structures in the exports - ContainerResources would probably be a good choice. within these ContainerResources you would again be free to choose the structure and the existing export mechanisms would probably only have to be adapted very little. only the creation of the exports could/must be checked, because up to now temporary directories have always been created locally, the data to be exported created in them and then zipped. this is error-prone (because explicit file names and paths have to be used) but also space-intensive, because almost twice the storage space is required during the creation of an export. furthermore, these temporary files must of course always be tidied up so that they do not unnecessarily occupy the hard disk space.

When using ContainerResources, it would make sense to use ResourceCollections, as the export tab of an object can contain any number of exports. this would probably allow you to simply use the ResourceCollectionGUI for the display.

an alternative would be for exports to be a kind of abstraction of a file from the components' point of view, to which the components make their contributions (this could presumably also simply be a ZIP, but the components should preferably never have to work with file names or paths themselves). these files or streams could then simply be saved as (normal) resources in the IRSS, in which case you would benefit from the functionality of the revisions (versioning of the resource) and could do without the ResourceCollection. This variant would probably require a major reorganisation on the part of the exporting components, but perhaps this would be the better option for the future.

in any case, you would still have to check whether you want to implement a migration of the previous export files. as these export files are currently distributed throughout the file system, they are quite difficult to capture and migrate. in my opinion, you could also point out in the releases notes of ILIAS 10 that exports before (in 9) should be downloaded and archived, as these are not migrated to ILIAS 10. this would allow you to remove the old export files for ILIAS 10 and simply start again.

as i said, i am at your disposal if anyone would like to discuss this topic with me.

JourFixe, ILIAS [jourfixe], 13 MAY 2024 : We highly appreciate this suggestion and schedule the feature for ILIAS 10 / trunk.

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}

Privacy

Information in privacy.md of component: updated on {date} by {user} | no change required

Approval

Approved at {date} by {user}.