feat: improve attachment storage for API

[cheywood]

• Attachments are stored in note-specific folder
• Attachment filenames are retained

This mirrors the behaviour for attachments created in the web UI, bringing the following benefits:

• Attachments get deleted (edit: and moved) along with the note
• Attachments don't clutter the directory alongside the note
• Non WYSIWIG editors which consume the API provide a better experience (via filenames not being replaced by random strings)
• Consistency with web

Most of the code is based on what's used in Text.

If the API wasn't already public I would switch the name of the return element for image creation to path (from filename). As there likely isn't any project consuming the API yet this may not be a bad idea.

Addresses part of #1623.

[enjeck]

Thanks for working on this and for raising question at #1623. I need time to read through the previous discussions when the current API was implemented before I can properly review this

[cheywood]

Thanks @enjeck! 🙏

Once this is resolved I'll get a release of Iotas out using the API :)

[cheywood]

Oh hrmm yeah reading back through the discussion I picked up that this impacts moving notes between categories too; without this fix the attachments are left in the previous location, disconnected from the note.

[enjeck]

I picked up that this impacts moving notes between categories too; without this fix the attachments are left in the previous location, disconnected from the note.

Yes, also previously reported at #1470

[enjeck]

Like I mentioned at #1623 (comment), I like the idea of using the original file name instead of a random text. But concerned about the new link structure. Apart from the concerns with using the file ID, I wonder how backwards compatible it is. I wonder if it's easier to just keep the existing struture in the meantime and instead explore moving things around when the category is changed.

[cheywood]

Like I mentioned at #1623 (comment), I like the idea of using the original file name instead of a random text. But concerned about the new link structure. Apart from the concerns with using the file ID, I wonder how backwards compatible it is. I wonder if it's easier to just keep the existing struture in the meantime and instead explore moving things around when the category is changed.

Responded over at #1623

[JuliaKirschenheuter]

Dear @cheywood

do you need some help with this PR to move forwards? If you have some open questions, please raise your hand and we will look how to help you!

[enjeck]

Dear @cheywood

do you need some help with this PR to move forwards? If you have some open questions, please raise your hand and we will look how to help you!

@JuliaKirschenheuter there are open questions in #1623. We need to decide if we happy with the approach suggested there

[cheywood]

Dear @cheywood

do you need some help with this PR to move forwards? If you have some open questions, please raise your hand and we will look how to help you!

Thanks @JuliaKirschenheuter , it would be great to see this (or something like this) merged. As @enjeck has identified it's just waiting on a decision.