Let's see...

+1
This would broaden the application range of orgzly a lot!

It would be so awesome if you could attach images directly from clipboard. And maybe (that's probably asking too much) if it's possible to take photos and handwritten notes on the spot - that would be totally mind-blowing. Then you can take notes anywhere - even during a math lecture or something like that. Especially if you have a stylus (hello Galaxy Note)

#147
#170

Org mode
Version 9.3

Org-Attach has been refactored and extended

Org attach has been refactored and the functionality extended. It should now be easier to understand how it works. A few improvements and extra options have been added as well.

From the initial comment in org-attach source-code:

Attachments are managed either by using a custom property DIR or by using property ID from org-id. When DIR is defined, a location in the filesystem is directly attached to the outline node. When org-id is used, attachments are stored in a folder named after the ID, in a location defined by org-attach-id-dir. DIR has precedence over ID when both parameters are defined for the current outline node (also when inherited parameters are taken into account).

https://orgmode.org/Changes.html

I'm interested in working on this. My understanding of the use cases are mainly two

1. When inside a note, insert a photo by launching the camera app
2. From another app, share a photo to orgzly to save it in a new note

In both cases, save the file as a copy locally in the org repository

Am I describing the use cases accurately? Interested to hear more

Couldn't the second use case be tweaked to allow selecting any file, instead of just an image?

I'm interested in working on this. My understanding of the use cases are mainly two

1. When inside a note, insert a photo by launching the camera app
2. From another app, share a photo to orgzly to save it in a new note

In both cases, save the file as a copy locally in the org repository

Am I describing the use cases accurately? Interested to hear more

As mentioned above, any file should be attached. Like attachments of an e-mail software.

Where seems to lie one difficulty is in the compatibility of paths and syntax between orgmode and orgzly.

In both cases, save the file as a copy locally in the org repository

Right. Save a copy of the file. Or move the file. (Personally I never use links here).
https://orgmode.org/manual/Attachment-defaults-and-dispatcher.html#Attachment-defaults-and-dispatcher

Not sure what you mean by “org repository”.
Ideally this results in the same directory structure that org-mode creates: A “data” directory with a two-level subfolder structure for all uuids.
Each node/heading that has at least one attachment gets a uuid as ID property. Thus one can change the node’s name without the attachment folder having to be touched.

Where seems to lie one difficulty is in the compatibility of paths and syntax between orgmode and orgzly.

Looks like there might be two different desires on managing the paths?

Ideally this results in the same directory structure that org-mode creates: A “data” directory with a two-level subfolder structure for all uuids. Each node/heading that has at least one attachment gets a uuid as ID property. Thus one can change the node’s name without the attachment folder having to be touched.

This is one way, I understand it is the org-attach way. The file is stored in a two-level subfolder within "data", and accessed via "attachment:" Link. This will be a bit more work to fully implement because orgzly currently don't know how to resolve "attachment:" links.

* Heading
:PROPERTIES:
:ID: 82bd9766-d8bd-418f-a5bb-5c569e488915
:END:
[[attachment:image.jpg]]

(The file image.jpg lives in a subfolder data/82/82bd9766-d8bd-418f-a5bb-5c569e488915)

The other way is simply storing the file into one subfolder that holds all attachments. The file can then be accessed via "file:" Link. With #496 implemented, user can control where the subfolder is to resolve the relative path starting with "file:".

* Heading
[[file:image.jpg]]

(The file image.jpg lives in the same folder as the org file)

Which one of the two ways to organize the paths would we prioritize for?

Actually #582 already supported use case 2: receiving shared image and link to the (absolute) path of the content. But it lacks the ability to copy the image.

:ID: 82bd9766-d8bd-418f-a5bb-5c569e488915
(The file image.jpg lives in a subfolder data/82/82bd9766-d8bd-418f-a5bb-5c569e488915)

It would actually be in data/82/bd9766-d8bd-418f-a5bb-5c569e488915/, since the first two characters aren't used in the name of the subdirectory.

Which one of the two ways to organize the paths would we prioritize for?

I would clearly prioritze the first way (uuids and “attachment:“-links). Like this it becomes really easy to quickly add a new note, add the attachment, and forget about it.
The charming part of this way is that the user does not have to worry about the attachment directory at all.

In org I often don’t bother linking files - I just move them into the attachment directory of a new node without even renaming them.

Which one of the two ways to organize the paths would we prioritize for?

I would clearly prioritze the first way (uuids and “attachment:“-links). Like this it becomes really easy to quickly add a new note, add the attachment, and forget about it.
The charming part of this way is that the user does not have to worry about the attachment directory at all.

In org I often don’t bother linking files - I just move them into the attachment directory of a new node without even renaming them.

How would it work if you share a file to Orgzly, from a different app?

When receiving a file from a different app, Orgzly can choose to save a copy. Normally it cannot delete or move the shared file.

We need to consider whether the existing behavior as in #582 needs to be supported in some way - it simply add the link of the shared file name into the note content without copying.

When receiving a file from a different app, Orgzly can choose to save a copy. Normally it cannot delete or move the shared file.

We need to consider whether the existing behavior as in #582 needs to be supported in some way - it simply add the link of the shared file name into the note content without copying.

I think that behaviour should be optimized, since it is not a relative path (incompatible with orgmode).

Where seems to lie one difficulty is in the compatibility of paths and syntax between orgmode and orgzly.

Looks like there might be two different desires on managing the paths?

Ideally this results in the same directory structure that org-mode creates: A “data” directory with a two-level subfolder structure for all uuids. Each node/heading that has at least one attachment gets a uuid as ID property. Thus one can change the node’s name without the attachment folder having to be touched.

This is one way, I understand it is the org-attach way. The file is stored in a two-level subfolder within "data", and accessed via "attachment:" Link. This will be a bit more work to fully implement because orgzly currently don't know how to resolve "attachment:" links.

* Heading
:PROPERTIES:
:ID: 82bd9766-d8bd-418f-a5bb-5c569e488915
:END:
[[attachment:image.jpg]]

(The file image.jpg lives in a subfolder data/82/82bd9766-d8bd-418f-a5bb-5c569e488915)

The other way is simply storing the file into one subfolder that holds all attachments. The file can then be accessed via "file:" Link. With #496 implemented, user can control where the subfolder is to resolve the relative path starting with "file:".

* Heading
[[file:image.jpg]]

(The file image.jpg lives in the same folder as the org file)

Which one of the two ways to organize the paths would we prioritize for?

I am using attachments more intensively on orgmode lately. It seems to me that orgzly should resolve "attachment" links for compatibility.

It is very fast to create links using attachments feature. Orgmode looks if there is a PROPERTY with a DIR (or ID) and searchs in it the linked or to be linked file. And it can have inheritance, like tags, so there is no needed to add a PROPERTY in every heading.

* Attachments
:PROPERTIES:
:DIR:      data/MULTIMEDIA/
:END:
[[attachment:image.jpg]]

** org-attach-use-inheritance
[[attachment:image.jpg]]

* Attachments 2
:PROPERTIES:
:ID:       20210328T171842.438103
:END:
[[attachment:image.jpg]]

** org-attach-use-inheritance
[[attachment:image.jpg]]

Is this feature finished?

Which one of the two ways to organize the paths would we prioritize for?

I prefer the first one, because I don't want to redefine an attachment data management, like how to naming the attachment folder. But the second is simple for implementation.

#1 (comment)

Which one of the two ways to organize the paths would we prioritize for?

I prefer the first one, because I don't want to redefine an attachment data management, like how to naming the attachment folder. But the second is simple for implementation.

Where seems to lie one difficulty is in the compatibility of paths and syntax between orgmode and orgzly.

Looks like there might be two different desires on managing the paths?

Ideally this results in the same directory structure that org-mode creates: A “data” directory with a two-level subfolder structure for all uuids. Each node/heading that has at least one attachment gets a uuid as ID property. Thus one can change the node’s name without the attachment folder having to be touched.

This is one way, I understand it is the org-attach way. The file is stored in a two-level subfolder within "data", and accessed via "attachment:" Link. This will be a bit more work to fully implement because orgzly currently don't know how to resolve "attachment:" links.

* Heading
:PROPERTIES:
:ID: 82bd9766-d8bd-418f-a5bb-5c569e488915
:END:
[[attachment:image.jpg]]

(The file image.jpg lives in a subfolder data/82/82bd9766-d8bd-418f-a5bb-5c569e488915)

The other way is simply storing the file into one subfolder that holds all attachments. The file can then be accessed via "file:" Link. With #496 implemented, user can control where the subfolder is to resolve the relative path starting with "file:".

* Heading
[[file:image.jpg]]

(The file image.jpg lives in the same folder as the org file)

Which one of the two ways to organize the paths would we prioritize for?

Hi

Maybe you could implement firstly the second way?

It would consist just in an option where we would set the attachments path.
And orgzly would just have to interpret the "attachment" links.

That would be a good start