Upgrade Storagepdf attachments: parent directory naming and one click access
Hi,
It would be nice if the directory structure of attachments directory reflects that of collections and sub-collections.
If I create collections "parent1", "parent2" and a sub-collections "child11" for "parent1" and "child21", "child22" for "parent2", whenever I save a pdf attachment for an item in "child22" it should be saved to "attachments/parent2/child22/<somename>" where <somename> can be customized with "attachmentRenameFormatString". In order to make <somename> unique we could append it with a unique number, instead of saving it inside a directory named with unique number as is the current practice.
This presents an intuitive interface to the user. A user may have a number of reasons to access a pdf file, for example, to have a quick look at the pdf, to make an attachment to an email, to backup, you name it. This removes the necessary requirement of having to use a particular interface (ie using zotero on top of firefox) all the time.
Additionally it would be a nice feature to open the only attachment when an item is double clicked.
Thinking from the point of view of a developer, I have the following suggestions. First to save all the attachments to "storage/<some_unique_name>" and then to make a soft/hard link to it from "attachments/parent2/child22/<somename>". Hard links are safer against deletion but complete deletion of attachments is tricky. However I notice that shared items are not handled correctly now anyway during deletion.
Please feel free to comment.
cheers,
Krishna.
It would be nice if the directory structure of attachments directory reflects that of collections and sub-collections.
If I create collections "parent1", "parent2" and a sub-collections "child11" for "parent1" and "child21", "child22" for "parent2", whenever I save a pdf attachment for an item in "child22" it should be saved to "attachments/parent2/child22/<somename>" where <somename> can be customized with "attachmentRenameFormatString". In order to make <somename> unique we could append it with a unique number, instead of saving it inside a directory named with unique number as is the current practice.
This presents an intuitive interface to the user. A user may have a number of reasons to access a pdf file, for example, to have a quick look at the pdf, to make an attachment to an email, to backup, you name it. This removes the necessary requirement of having to use a particular interface (ie using zotero on top of firefox) all the time.
Additionally it would be a nice feature to open the only attachment when an item is double clicked.
Thinking from the point of view of a developer, I have the following suggestions. First to save all the attachments to "storage/<some_unique_name>" and then to make a soft/hard link to it from "attachments/parent2/child22/<somename>". Hard links are safer against deletion but complete deletion of attachments is tricky. However I notice that shared items are not handled correctly now anyway during deletion.
Please feel free to comment.
cheers,
Krishna.
This is an old discussion that has not been active in a long time. Instead of commenting here, you should start a new discussion. If you think the content of this discussion is still relevant, you can link to it from your new discussion.