In the user management a new tool is implemented to export the user data. What exactly is exportable is defined in the subtasks for this issue.
An example how this could look like is attached as mockups.
NOTE: the list in the subtasks is subject of discussion and change. It has been priorities from top to down and during implementation we will see how fast we can deliver those elements and wether we will skip elements because they are to complicated for now.
The generation of the data export can take some time, thus it should be implemented asynchronously. Once the export archive is generated, it must be downloadable from the user profile. For example an export tab could be implemented from which the export process can be triggered and where existing export can be downloaded.
When an export is generated, the user can see the export in his settings as well and download it from there (new segment next to the disclaimer).
The user manager must be able to get a link that he can send to the user to download the export he requested. The user however can not trigger the export generation.
Since this duplicates all data it could make sense to add an expiration date to the exports and automatically delete them after some time if feasible.
To implement this feature a new interface should be implemented similar to the UserDataDeletable or the UserDataDeletable should be extended.
Since the export is now moved, UserDataDeletable.deleteUserData can be refactored to remove the archivePath and move this functionality to the new UserDataExportable interface.
Wherever the UserDataDeletable is implemented it must be checked if it makes sense to add the new interface and move the export code or implement it.
The interface must provide methods to generate the exports and to perform a "dry-run". The dry run version would only generate a list of URL's to the exported objects with some label, date and context information if this is possible at all.
The ideal is to use the same tool to show the user a list of items that "belong" to him and provide him a way to access those items. This could also be displayed to the user profile somewhere as a big list.
Since this can be very costly we need to consider some optimisations there by user not letting generating the list e.g. more than once a day or by excluding all data that can not be gathered quickly using database queries (E.g. file things). Those can be added later when we have better solutions for this.
The export must be readable but not win a beauty contest. Each exported decides what format is best: XML, HTML, Excel, File - whatever is already there.
For many data objects such as forum posts, efficiency statements the portfolio handler can be used to generate appropriate HTML. For the user profile an XML serialisation can be made or an HTML fragment is created.
As a bonus, an imsmanifest.xml could be generated by the exporter and the wiki-offline tools be bundled in the export to make the export easily browsable by the user. But this is only done if feasible.