Content
View differences
Updated by Judith Roth 8 months ago
In <mention class="mention" data-id="67403" data-type="work_package" data-text="#67403">#67403</mention> Wieland suggested we could introduce and use a new API endpoint for uploading attachments belonging to collaborative documents.
The current API endpoints for uploading attachments for a document (`/api/v3/documents/<document_id>/attachments`) and showing them (`api/v3/attachments/<attachment_id>/content`) have the following shortcomings:
* The URL is guessable since IDs are just incremented (but if a user is not allowed to see a file, it will only return a file not found error)
* ~~It does not use the configured storage endpoint (S§ or local)~~ (in fact it seems like it does consider this)
* ??? (Please add if there are more things that are problematic about this API endpoint)
Questions:
* When migrating existing documents, would we also have to / want to update the existing attachment URLs in those?
* <br>
<br>
While it would be nice to address these shortcomings now, the scope for V1 of collaborative documents is already pretty big.
<br>
<br>
The current API endpoints for uploading attachments for a document (`/api/v3/documents/<document_id>/attachments`) and showing them (`api/v3/attachments/<attachment_id>/content`) have the following shortcomings:
* The URL is guessable since IDs are just incremented (but if a user is not allowed to see a file, it will only return a file not found error)
* ~~It does not use the configured storage endpoint (S§ or local)~~ (in fact it seems like it does consider this)
* ??? (Please add if there are more things that are problematic about this API endpoint)
Questions:
* When migrating existing documents, would we also have to / want to update the existing attachment URLs in those?
* <br>
<br>
While it would be nice to address these shortcomings now, the scope for V1 of collaborative documents is already pretty big.
<br>
<br>