OS4 meeting export

[r-peschke]

Currently the OS4-meeting export doesn't export the content of the mediafiles, only the meta data of mediafiles will be exported.
Usually there is no need to export the mediafiles, because you could clone it in the OS4-instance.

If someone wants to use such an export as meeting-backup the content of the mediafiles is not included and we should warn the user about this.
Alternatively we could include the mediafiles in the export. But this would lead to big json-files, imagine a video or mega-documents and we have to think about organization-wide resources.
The import technically reads the whole data into the browser and sends it to the backend to store. We may get and currently we have problems to import such big json-files.

Let's look for a good solution!

[luisa-beerboom]

If we export the mediafile metadata, I could imagine a system where we allow the client to upload the actual mediafiles separately.

Perhaps something like this:

1. Meeting import: The meeting is created without mediafiles, but the mediafile data is saved in a special attribute (let's call it shadow_files for now)
2. The client may then call a second step action (something like meeting.specify_shadow_files) wherein the actual files may be uploaded (modified mass mediafile.upload) and interconnected with the meeting in accordance with the saved meta data.

All the backend would have to do in case of this new action is

• Require a mapping to the appropriate mediafile id in the meta data
• Normally upload the file using the given metadata saved for that id (Including mimetype checks of course). This'll work perfectly by just calling mediafile.upload internally.
• Ensure all the attachments and other metadata that isn't part of mediafile.upload etc. of the old file are re-included as well

As far as the client is concerned this may still be packed up in one nice bundle, by turning the import file into a zip file containing both the usual json, as well as all the relevant files named by their former id.
The client can then unzip, call the usual meeting.import first, wait till it's done and then call this shadowfiles action for the files afterward, reading the old id from the filename.
Or the client could just allow the user to do it manually, whatever suits them really.