After talking with Wieland again and doing some research, I try to summarize this anew.

First: We need to distinguish between attachments that were uploaded in the Editor Begin of the insertionand are supposed to be rendered inside the textEnd of the insertion ("inline attachments") and attachments that were uploaded in the "Files" tab.

### Current state

In the **classic documents** module, there is no difference between inline attachments and attachments uploaded in the "Files" tab. All of them are shown in the "Files" tab.

In **work packages**, inline attachments (uploaded with CKEditor), e.g. images, are shown in the "Files" tab as well. If such a file is removed from the work package text, it is not removed from the "Files" tab. Begin of the insertion

End of the insertion Begin of the deletion
End of the deletion However, files that have been added to a **comment to a work package**, are not shown in the "Files" tab. If a comment with a file (e.g. image) is created and the text is edited and the file link removed, we also remove the file from the database and storage. This is important for GDPR compliance, since the user would otherwise have no way to delete the file.

Wieland argued, that it would be nice for users to distinguish between inline attachments and attachments uploaded in the "Files" tab, because in documents often many screenshots are included and only some important files added as attachments. Then the "Files" tab would be cluttered with screenshots.

We also have to be GDPR compliant and remove files from the storage, when the user does not want us to keep them (e.g. deletes the file).

Another important topic is that we want to have document versions in the future. Then multiple versions of a document could include the same Begin of the insertioninlineEnd of the insertion attachment.

### There are several options

<br>

1. We list all files in the Begin of the insertion**Files**End of the insertion Begin of the deletion filesEnd of the deletion tab, regardless of how they were uploaded. To make it easier for users we could distinguish here between files uploaded in the editor and files uploaded in the files tab. We do not delete files when the user removes the link in the document text.
&nbsp;Pro: 
   - We are easily able to provide a &quot;delete&quot; link for each attachment (although we probably should warn the user when the file is still used in the document or a document version) and are GDPR compliant with this.
   - Easy to implement
 Contra:
   - Maybe cluttered view?
   - Users could forget they have to manually remove the file after they deleted the link to the file in the document

<br>

2. In the Begin of the insertion**Files**End of the insertion Begin of the deletion &amp;quot;Files&amp;quot;End of the deletion tab we only list files that were uploaded in the Begin of the insertion**Files**End of the insertion Begin of the deletion &amp;quot;Files&amp;quot;End of the deletion tab and ignore all files that were uploaded in the editor. Begin of the insertionA normal deletion of an image from the rich text does not delete the file from the storage. By default we keep inline attachments and don&#39;t delete them automatically.  To address GDPR: Within the rich text, on the block of the inline attachment, we offer a special action for admins, to &quot;Delete the image for all the whole history&quot;. Ideally, that action needs to me confirmed. The admin needs to feel confident in what she is doing. End of the insertion
 Pro:
   - Probably nicer for users, less clutter on large documents
Begin of the insertion   - Simple implementation
   - Allows GDPR requirements
   - Allows keeping inline attachments around for restoring older versions of a rich text, even if newer versions had removed an inline attachment.
End of the insertion  Contra:
   - Begin of the insertion~~WeEnd of the insertion Begin of the deletion WeEnd of the deletion somehow need to know when the last occurrence of a link to a file was deleted from a document (and in the future also from the document versions) so that we can automatically delete it to be compliant with GDPR. This could be complicated and probably slow for huge documents with many versions =&gt; high implementation effort and maybe bad Begin of the insertionperformance~~
   - We might store more files than really necessary.End of the insertion Begin of the deletion performanceEnd of the deletion


As always, feel free to edit and add options, pros and contras as you see fit.