starred/papermerge

Fork 0

mirror of https://github.com/ciur/papermerge.git synced 2026-04-25 12:05:58 +03:00

[GH-ISSUE #398] keep document directory structure on disk #311

New issue

Open

opened 2026-02-25 21:31:40 +03:00 by kerem · 6 comments

kerem commented

2026-02-25 21:31:40 +03:00

Owner

Originally created by @qq7te on GitHub (Jul 5, 2021).
Original GitHub issue: https://github.com/ciur/papermerge/issues/398

Originally assigned to: @ciur on GitHub.

Is your feature request related to a problem? Please describe.
My company's problem is that we already have a few thousand documents that we have in our company's shared storage on disk. We would like to physically keep them in that directory structure (the actual storage could be moved) , and import them into PaperMerge in that same directory layout.

I can see that once we import, all the documents are saved in a flat hierarchy on disk.

The ultimate goal is to be able to access the documents through our regular network file browser interfaces, but also view it through papermerge's UI.

Is that possible? Is this something that you are working on? Is this something that we could contribute to the project?

Describe the solution you'd like
I think that with some effort one could modify the storage portion of papermerge-core to do this.

Describe alternatives you've considered
I don't know... :(

Originally created by @qq7te on GitHub (Jul 5, 2021). Original GitHub issue: https://github.com/ciur/papermerge/issues/398 Originally assigned to: @ciur on GitHub. **Is your feature request related to a problem? Please describe.** My company's problem is that we already have a few thousand documents that we have in our company's shared storage on disk. We would like to physically keep them in that directory structure (the actual storage could be moved) , and import them into PaperMerge in that same directory layout. I can see that once we import, all the documents are saved in a flat hierarchy on disk. The ultimate goal is to be able to access the documents through our regular network file browser interfaces, but also view it through papermerge's UI. Is that possible? Is this something that you are working on? Is this something that we could contribute to the project? **Describe the solution you'd like** I think that with some effort one could modify the storage portion of `papermerge-core` to do this. **Describe alternatives you've considered** I don't know... :(

kerem added the

enhancement

feature request

labels

2026-02-25 21:31:40 +03:00

kerem commented

2026-02-25 21:31:40 +03:00

Author

Owner

@ciur commented on GitHub (Jul 5, 2021):

Is that possible?

Yes, it is possible

Is this something that you are working on?

Not at this point in time; now I am refactoring frontend.

Is this something that we could contribute to the project?

Yes, absolutely!
And you are perfectly right, code in concern is in papermege-core.

Thank you for taking you time and opening this issue, I will keep it in mind.

@ciur commented on GitHub (Jul 5, 2021): > Is that possible? Yes, it is possible > Is this something that you are working on? Not at this point in time; now I am refactoring frontend. > Is this something that we could contribute to the project? Yes, absolutely! And you are perfectly right, code in concern is in papermege-core. Thank you for taking you time and opening this issue, I will keep it in mind.

kerem commented

2026-02-25 21:31:40 +03:00

Author

Owner

@new0ne commented on GitHub (Jul 14, 2021):

+1 from me. I'd love to see that feature too. Thats really the only function which i am missing.
Having a proper folder structure on disk as well as having the webinterface would make this just THE PERFECT solution in my eyes.

@new0ne commented on GitHub (Jul 14, 2021): +1 from me. I'd love to see that feature too. Thats really the only function which i am missing. Having a proper folder structure on disk as well as having the webinterface would make this just THE PERFECT solution in my eyes.

kerem commented

2026-02-25 21:31:40 +03:00

Author

Owner

@lucasff commented on GitHub (Jan 20, 2022):

I'd like the same feature as well <3

@lucasff commented on GitHub (Jan 20, 2022): I'd like the same feature as well <3

kerem commented

2026-02-25 21:31:40 +03:00

Author

Owner

@ciur commented on GitHub (Jan 21, 2022):

This feature is being requested frequently.
The plan is to make papermerge all RESTful and provide this sort of features via 3rd party applications. The 3rd party application will communicate with papermerge via REST API.
Here is a more detailed explanation from a similar ticket comment.

@ciur commented on GitHub (Jan 21, 2022): This feature is being requested frequently. The plan is to make papermerge all RESTful and provide this sort of features via 3rd party applications. The 3rd party application will communicate with papermerge via REST API. Here is a more detailed explanation [from a similar ticket comment](https://github.com/papermerge/papermerge-core/issues/13#issuecomment-1018833512).

kerem commented

2026-02-25 21:31:40 +03:00

Author

Owner

@rmatte commented on GitHub (Feb 17, 2023):

I really think the documents should be stored on disk in a hierarchy instead of a flat structure and this should be just the way that papermerge works natively rather than relying on some third party package and the API. If for some reason we were ever to lose the papermerge database due to corruption or something (I'm aware that there's a way to back it up, but still, things can happen) then at that point the documents on disk haven't been renamed or organized in to folders like we've done within papermerge. So making any sense of those documents would be a huge chore.

See my feature request here which is basically the same as what's being asked in this ticket and would make the on disk storage make much more sense and be much better in general: https://github.com/ciur/papermerge/issues/526

I don't see any advantage at all to storing the documents in their original filenames all in one directory like the software is currently doing. It's a mess to work with outside of the application. This also seems like it would be fairly simple to code. Code a migration step which runs once to re-organize any existing documents on disk based on the information in the database, then have hooks in place in the code when documents are renamed and moved to mirror those actions on disk. Perhaps have sub-directories representing each file so that you can store multiple file versions in them.

I've seen that you have a hosted solution of this with support offered that seems to be taylored for small businesses. If I were running a small business I wouldn't even consider using this software without the ability to have the files and folders organized on disk as well, from a document integrity, backup, and ease of access standpoint. I'm not even currently comfortable using this for my home documents because I don't like the idea of being completely tied to a database for my document organization. In an absolute worst case scenario I want to know that my documents are organized properly on disk as well as in papermerge.

I've been working in IT since 2005 and I've seen production databases become corrupted many many times. It can and does happen. For something as important as a person or company's documents, it's very important to not be relying 100% on a database for document organization and storage.

@rmatte commented on GitHub (Feb 17, 2023): I really think the documents should be stored on disk in a hierarchy instead of a flat structure and this should be just the way that papermerge works natively rather than relying on some third party package and the API. If for some reason we were ever to lose the papermerge database due to corruption or something (I'm aware that there's a way to back it up, but still, things can happen) then at that point the documents on disk haven't been renamed or organized in to folders like we've done within papermerge. So making any sense of those documents would be a huge chore. See my feature request here which is basically the same as what's being asked in this ticket and would make the on disk storage make much more sense and be much better in general: https://github.com/ciur/papermerge/issues/526 I don't see any advantage at all to storing the documents in their original filenames all in one directory like the software is currently doing. It's a mess to work with outside of the application. This also seems like it would be fairly simple to code. Code a migration step which runs once to re-organize any existing documents on disk based on the information in the database, then have hooks in place in the code when documents are renamed and moved to mirror those actions on disk. Perhaps have sub-directories representing each file so that you can store multiple file versions in them. I've seen that you have a hosted solution of this with support offered that seems to be taylored for small businesses. If I were running a small business I wouldn't even consider using this software without the ability to have the files and folders organized on disk as well, from a document integrity, backup, and ease of access standpoint. I'm not even currently comfortable using this for my home documents because I don't like the idea of being completely tied to a database for my document organization. In an absolute worst case scenario I want to know that my documents are organized properly on disk as well as in papermerge. I've been working in IT since 2005 and I've seen production databases become corrupted many many times. It can and does happen. For something as important as a person or company's documents, it's very important to not be relying 100% on a database for document organization and storage.

kerem commented

2026-02-25 21:31:40 +03:00

Author

Owner

@Robubble commented on GitHub (Jan 3, 2026):

It could already help if paperless would save the original file path as a fall-back and offer csv export of this data.
Databases are nice and the approach of centralized file management has its reason but it would be nice if you could keep track pf the original location (also in case of projects that consists of multiple file types)

@Robubble commented on GitHub (Jan 3, 2026): It could already help if paperless would save the original file path as a fall-back and offer csv export of this data. Databases are nice and the approach of centralized file management has its reason but it would be nice if you could keep track pf the original location (also in case of projects that consists of multiple file types)