Feature Wiki

Information about planned and released features

Tabs

Get Rid of Single Objects Export While Exporting Containers

1 Initial Problem

When exporting an entire container object (e.g., a course), export files are also created in its single content objects.
This applies at least the first time the export is run, when no existing export files of those single objects can be re-used.

Moreover, re-using existing export files of single objects can often not be chosen because those objects have been modified in the meantime and the user wants to have the current version each.
This way, more and more export files arise which aren't needed at all because the exporting user simply wants to have an up-to-date export file for the entire container.
The single objects' contents are both stored in specific export file and in the container's export file, thus wasting a lot of disk space (~ twice as much as necessary).
To clear this disk space again, all of the single objects have to be opened one by one in order to delete all of those object-specific export files nobody ever asked for.

With later occasions, exporting an entire container object can be done using existing single objects' export files, thus "saving" disk space. However, at that point the damage of wasting disk space is already done!
Saving disk space seems to me the only reason for that re-using feature because I cannot imagine a scenario in which a user explicitly wants to have outdated versions of objects in his/her export file (and even if so, you cannot even choose which one of the existing files is to be included in the export but it's always the last one).

So, this feature can only be understood as an "economizing policy". However, it doesn't fit the purpose, it comes too late when the disk space is already wasted, or put differently, it would be much more economic not to create those single objects' export files from the beginning.

2 Conceptual Summary

Exporting a container object only creates one export file which is containing all of the container's objects (resp., the selected ones).
No object-specific export files are created in that container.
In case some user wants to have object-specific export files, this can be done in the single object's "Export" tab.

3 User Interface Modifications

3.1 List of Affected Views

  • cat/export/
  • crs/export/
  • grp/export/
  • fold/export/
(and implicitly the export views of all object types)

3.2 User Interface Details

The "Select Resources" view of crs/export/ doesn't offer a "Last Export" and "Use Last Export File" column but only "Include in Export File" and "Omit Resource" columns.

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 Contact

  • Author of the Request: Suittenpointner, Florian [suittenpointner]
  • Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
  • Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

6 Funding

If you are interest in funding this feature, please add your name and institution to this list.

7 Discussion

Suittenpointner, Florian [suittenpointner], 04 Oct 2018:
I am aware of the fact that there might be technically reasons why the container export has been implemented in the way it is by now. However, please consider my arguments for the sake of disk space economy.

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

Last edited: 4. Oct 2018, 21:43, Suittenpointner, Florian [suittenpointner]