starred/papermerge

Fork 0

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

[GH-ISSUE #468] Document improvments #363

New issue

Closed

opened 2026-02-25 21:31:46 +03:00 by kerem · 5 comments

kerem commented

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

Owner

Originally created by @Solverz-0 on GitHub (Aug 1, 2022).
Original GitHub issue: https://github.com/ciur/papermerge/issues/468

Originally assigned to: @ciur on GitHub.

As a paperless-ngx user, I have tried papermerge, but it is lacking what I think are essential features, these feaures are enough to make me unable to switch to papermerge and papermerge has some really great features that paperless-ngx does not but they are not complete deal breakers.

I will explain the features I think would be amazing addtions to papermerge:

Extra data to "attach/link" to documents like Title, Archive serial number, Date created, Correspondent, Document type

These are different than tags and should be more "standard" fields.
These are what paperless-ngx uses and they are very useful for organising the documents and be able to find the document you need without too much digging.
Title - This can be substituted by the file name but I think having it show on the side when viewing the document would be nice to have.
Archive serial number - Some documents have to be kept physically and by having an ASN option you can cross reference the digital version with the physical version which would be in a folder ordered by increasing ASN's, for exmaple 1, 2, 3, 4.
Date created - The date the document was issued or received. Great for filtering through documents that were created on a specific day, really helps narrow things down when searching for a document. When I say created I do not mean added to papemerge I mean actually created or issued to the recipient.
Correspondent - Who the document was sent from or who you sent the document too, again this is helpful for filtering but also makes the organising of the documents more complete.
Document type - invoice, manual, contract, etc., Filtering again.

Ability to add multiple versions of a document to an existing document yourself.

I understand if you edit a document in the papermerge UI it creates new versions as papermerge is non-detructive, but being able to add modifed copies of the same document as multiple versions yourself manually would be very handy as sometimes documents change for some reason and you need both versions digitally and it is not nice having them show up in the UI as seperate documents which is what it would look like now if you upload multiple versions.

A notes field, to add notes to documents.

Sometimes you may need to add notes or a description of a document and by having a notes field which is linked to the documents individually would allow this.

This is just some of the main essential features that I think would make papermerge become even better than it already is.

Originally created by @Solverz-0 on GitHub (Aug 1, 2022). Original GitHub issue: https://github.com/ciur/papermerge/issues/468 Originally assigned to: @ciur on GitHub. As a paperless-ngx user, I have tried papermerge, but it is lacking what I think are essential features, these feaures are enough to make me unable to switch to papermerge and papermerge has some really great features that paperless-ngx does not but they are not complete deal breakers. I will explain the features I think would be amazing addtions to papermerge: 1. **Extra data to "attach/link" to documents like Title, Archive serial number, Date created, Correspondent, Document type** - These are different than tags and should be more "standard" fields. - These are what paperless-ngx uses and they are very useful for organising the documents and be able to find the document you need without too much digging. - **Title** - This can be substituted by the file name but I think having it show on the side when viewing the document would be nice to have. - **Archive serial number** - Some documents have to be kept physically and by having an ASN option you can cross reference the digital version with the physical version which would be in a folder ordered by increasing ASN's, for exmaple 1, 2, 3, 4. - **Date created** - The date the document was issued or received. Great for filtering through documents that were created on a specific day, really helps narrow things down when searching for a document. When I say created I do not mean added to papemerge I mean actually created or issued to the recipient. - **Correspondent** - Who the document was sent from or who you sent the document too, again this is helpful for filtering but also makes the organising of the documents more complete. - **Document type** - invoice, manual, contract, etc., Filtering again. 2. Ability to add multiple versions of a document to an existing document yourself. - I understand if you edit a document in the papermerge UI it creates new versions as papermerge is non-detructive, but being able to add modifed copies of the same document as multiple versions yourself manually would be very handy as sometimes documents change for some reason and you need both versions digitally and it is not nice having them show up in the UI as seperate documents which is what it would look like now if you upload multiple versions. 3. A notes field, to add notes to documents. - Sometimes you may need to add notes or a description of a document and by having a notes field which is linked to the documents individually would allow this. This is just some of the main essential features that I think would make papermerge become even better than it already is.

kerem

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

closed this issue
added the
enhancement

feature request
labels

kerem commented

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

Author

Owner

@ciur commented on GitHub (Aug 2, 2022):

@Solverz-0,

Regarding first point document fields.
There is a good reason why the fields you mention (ASN, document type, correspondent) are not implemented.
It is because what fields should document have, the way you put it "standard fields" - is very debatable; in the end, needs for specific fields depends on owns use cases, workflows.

Instead of having fields specific fields X, Y, Z, ... and avoid "please add field A, B, C... " feature requests, Papermerge decided on different route - metadata.

Metadata is a way of adding what fields (type) you want and how many of them you need.
For example, if you need ASN - just add a field of type say integer, which will automatically increment.
If you need document type field - add that metadata field.

Now, metadata was (poorly) part of the feature set - up until version 2.0.
In version 2.1 I temporarily removed (because of rewrite) - thus you won't see it mentioned in user manual.
In version 2.2 metadata (the way I describe it above) will be re-introduced.
If implemented right, metadata can be very powerful and flexible solution for adding a wide range of custom field types.

Regarding second point, this one:

Ability to add multiple versions of a document to an existing document yourself

This one is actually last feature I will add before current papermege 2.1.0ax (alpha) enters into beta (i.e feature complete phase). I had this in my mind since more than a year and I needed in my own use cases many times.
In papermerge terminology this will be called "merging documents" and you will see it soon appearing in user manual.

@ciur commented on GitHub (Aug 2, 2022): @Solverz-0, Regarding first point document fields. There is a good reason why the fields you mention (ASN, document type, correspondent) are not implemented. It is because what fields should document have, the way you put it "standard fields" - is very debatable; in the end, needs for specific fields depends on owns use cases, workflows. Instead of having fields specific fields X, Y, Z, ... and avoid "please add field A, B, C... " feature requests, Papermerge decided on different route - metadata. Metadata is a way of adding what fields (type) you want and how many of them you need. For example, if you need ASN - just add a field of type say integer, which will automatically increment. If you need document type field - add that metadata field. Now, metadata was (poorly) part of the feature set - [up until version 2.0](https://docs.papermerge.io/2.0.0/User%27s%20Manual/metadata.html). In version 2.1 I temporarily removed (because of rewrite) - thus [you won't see it mentioned in user manual.](https://docs.papermerge.io/master/User%27s%20Manual/index.html) In version 2.2 metadata (the way I describe it above) will be re-introduced. If implemented right, metadata can be very powerful and flexible solution for adding a wide range of custom field types. Regarding second point, this one: > Ability to add multiple versions of a document to an existing document yourself This one is actually last feature I will add before current papermege 2.1.0ax (alpha) enters into beta (i.e feature complete phase). I had this in my mind since more than a year and I needed in my own use cases many times. In papermerge terminology this will be called "merging documents" and you will see it soon appearing in user manual.

kerem commented

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

Author

Owner

@Solverz-0 commented on GitHub (Aug 2, 2022):

These are some good points thank you. I have gave the metadata option a go, how you explained and they do help in replacement of the mentioned "standard fields".

However there are a few things that I think would make them more easier to use:

Instead of having to re-type the meta data name out each time, once one is created have it available as a dropdown with search so you can easily select them for all documents. Guessing this will make it so it is not repeated in the sql database too? (Not a sql admin so unsure how this works)
Allow user to select required/mandatory meta data, so users do not forget what meta data they want all their documents to have which ensures completeness. Also maybe allow for conditions for if meta data should be mandatory based on if other meta data is used or not.
Allow for filtering to include meta data
Allow to expand text box area and wrap text based on text box size so it can be used for notes eaiser or longer value entries.

Additionally, when I fist started giving papermerge a trial I could not figure out how to add tags and after a google search I came across a reddit post which said to select a document you have to click the text box and then right click, whereas I was just right clicking before which showed greyed out menu items. I think just based on using other software that clicking, right or left should also sleect a document and if you want to open a document the user should click on the document icon or something similar instead.

Anyway, this is a really amazing product and a real competitor to paperless. Thank you for starting and maintaining this project!

@Solverz-0 commented on GitHub (Aug 2, 2022): These are some good points thank you. I have gave the metadata option a go, how you explained and they do help in replacement of the mentioned "standard fields". However there are a few things that I think would make them more easier to use: - Instead of having to re-type the meta data name out each time, once one is created have it available as a dropdown with search so you can easily select them for all documents. Guessing this will make it so it is not repeated in the sql database too? (Not a sql admin so unsure how this works) - Allow user to select required/mandatory meta data, so users do not forget what meta data they want all their documents to have which ensures completeness. Also maybe allow for conditions for if meta data should be mandatory based on if other meta data is used or not. - Allow for filtering to include meta data - Allow to expand text box area and wrap text based on text box size so it can be used for notes eaiser or longer value entries. Additionally, when I fist started giving papermerge a trial I could not figure out how to add tags and after a google search I came across a reddit post which said to select a document you have to click the text box and then right click, whereas I was just right clicking before which showed greyed out menu items. I think just based on using other software that clicking, right or left should also sleect a document and if you want to open a document the user should click on the document icon or something similar instead. Anyway, this is a really amazing product and a real competitor to paperless. Thank you for starting and maintaining this project!

kerem commented

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

Author

Owner

@w4tzmann commented on GitHub (Sep 15, 2022):

In version 2.2 metadata (the way I describe it above) will be re-introduced.

I know this is a very unpopular question, but is it already predictable when version 2.2 will come, or metadata will return? For me this data is extremely important, as I would like to build workflows on it.

I agree with the comments made by Solverz-0. I, too, would need defined metadata that is searchable, committed, reusable and ideally build on each other.

For example, I have a meta field "Doc-Type". If I then select invoice there, the invoice date and invoice amount fields are always to be filled. I can then search across all documents for type = invoice. An additional wish of mine would then be to establish a workflow, that points out missing invoices. So for example I have January, February, April and so it is clear that March is missing. By accessing the rest api(if necessary the DB), this could be realized with an third party solution.

@w4tzmann commented on GitHub (Sep 15, 2022): > In version 2.2 metadata (the way I describe it above) will be re-introduced. I know this is a very unpopular question, but is it already predictable when version 2.2 will come, or metadata will return? For me this data is extremely important, as I would like to build workflows on it. I agree with the comments made by Solverz-0. I, too, would need defined metadata that is searchable, committed, reusable and ideally build on each other. For example, I have a meta field "Doc-Type". If I then select invoice there, the invoice date and invoice amount fields are always to be filled. I can then search across all documents for type = invoice. An additional wish of mine would then be to establish a workflow, that points out missing invoices. So for example I have January, February, April and so it is clear that March is missing. By accessing the rest api(if necessary the DB), this could be realized with an third party solution.

kerem commented

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

Author

Owner

@ciur commented on GitHub (Sep 15, 2022):

but is it already predictable when version 2.2 will come,

Yes, absolutely! Metadata will return!

I just didn't want to delay the release anymore; since last stable release (2.0) 18 months passed, and besides the fact that I don't want to delay the release anymore -as it is sufficiently complex and thus its already challenging for me alone to test it. This is the reason why I decided to release 2.1 "earlier" and "sacrifice" metadata feature for the next release (2.2).

Similar to automates. They will be back after metadata.

@ciur commented on GitHub (Sep 15, 2022): > but is it already predictable when version 2.2 will come, Yes, absolutely! Metadata will return! I just didn't want to delay the release anymore; since last stable release (2.0) 18 months passed, and besides the fact that I don't want to delay the release anymore -as it is sufficiently complex and thus its already challenging for me alone to test it. This is the reason why I decided to release 2.1 "earlier" and "sacrifice" metadata feature for the next release (2.2). Similar to automates. They will be back after metadata.

kerem commented

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

Author

Owner

@ciur commented on GitHub (Dec 27, 2024):

Basically what is this ticket about - it is about introducing custom fields feature ( also known as metadata).

Custom fields i.e. metadata feature is now available in 3.3. Custom fields can be assigned to document type. Each document can be assigned to one document type.

In another words, custom fields are assigned to the documents via document types.

I am closing this ticket - as custom fields feature is now available.

https://docs.papermerge.io/3.3/user/custom-fields/

@ciur commented on GitHub (Dec 27, 2024): Basically what is this ticket about - it is about introducing custom fields feature ( also known as metadata). Custom fields i.e. metadata feature is now available in 3.3. Custom fields can be assigned to document type. Each document can be assigned to one document type. In another words, custom fields are assigned to the documents via document types. I am closing this ticket - as custom fields feature is now available. https://docs.papermerge.io/3.3/user/custom-fields/