jonaswinkler / paperless-ng

A supercharged version of paperless: scan, index and archive all your physical documents
https://paperless-ng.readthedocs.io/en/latest/
GNU General Public License v3.0
5.37k stars 355 forks source link

Notable things/possible improvements, coming from Docspell #53

Closed totti4ever closed 3 years ago

totti4ever commented 3 years ago

Hey Jonas, this absolutely looks amazing! I would have loved to see this half a year ago, especially the dashboard idea seems to be great!

I am kind of torn between Docspell and paperless-ng now, having just added all my files to Docspell, but really like your UI!

I was wondering what you think of the following things, which I think Docspell offers better:

  1. Tags, Correspondent, etc shown in overview
    I would say this is a must for me to not only filter using them but also see the attached metadata in search results and so on. Having this is also makes sense to only offer edit and not show details. Right now I have to open edit mode to see metadata
    Okay, just figured out (see last point) that tags are shown really well and the correspondent is made a prefix of the title, which I like less (looks weird when the title also uses colon). Plus it would be nice if those properties were clickable
  2. Show document in the browser
    right now there is just the ability to see the document in the edit mode. Clicking on the preview could for instance lead to the document itself (I think this is something, Paperless (original) offers as well)
  3. Concerned person
    I really really like that I can add the information to whome a letter had been addressed: me, my wife, both of us, which of the children.
  4. nested tags or tag categories
    This just helps a lot with organizing. Right now one has to workaround it by using some concerned-me, concerned-kid1, concerned-wife logic
  5. Direction of item
    I guess most people mainly this type of app for letters in a broader sense - and sometimes I just find it really useful to also throw in the things I send out, e.g. some application for public funds or something like that
  6. Syntax help
    Right now it only suggests the property, not the operator from what I saw. I loved the expert search from the original paperless!
  7. Corresponding person (detail of corresponding organization)
    I have to admit that I use this not that often so far, but I like the idea :-)
  8. User-specific filename
    Is this still possible like in original paperless?
  9. MariaDB/MySQL support
    is this planned?
  10. Multi-user support as already mentioned in #52
  11. multiple files per item
    I like the idea to sometimes put things together, which belong together. An alternative could be to add relations between items!

    • And please add a check if leaving edit mode with unsaved changes!
jonaswinkler commented 3 years ago

Hello, and thank you for your suggestions!

  1. Everything is shown on the card/in the table as much as the given space allows it. I'll have the Correspondent stand out a little more on large cards, if its available. Clickable properties: I suppose these should instantly apply a filter, which seems great to have.
  2. Yep, I just need to figure out where to put the buttons for that. The rest is already there.
  3. This is the correspondent of a document. This works in both ways.
  4. I've thought about this for myself and really like the idea. Have nested tags as in "bankstatement-account1" and "bankstatement-account2", filter by bankstatement to get all statements or by account1 to get just these. I'll add that to the roadmap.
  5. It seems you want separate fields for sender and recipient.
  6. The search is entirely different from upstream paperless. There's advanced syntax available, I just need to create the documentation for that. For now, you can look at https://whoosh.readthedocs.io/en/latest/querylang.html what the query language looks like.
  7. Correspondents can be anything, a person, an institution, a mail box from where the document came from, etc.
  8. Do you mean setting a custom filename format? That's still in the code and will remain there. However, they are still generated from the date, title, correspondent and so on. Entirely custom filenames won't be implemented. The entire point of this software is that you don't have to care about how the documents are stored on disk.
  9. Providing configuration options for that is easy, but making sure that it's working (now, and also in the future) is not. I'm running postgresql and can't make any promises about mysql. I'll think about it. As for now, even SQLite is reasonable for this kind of application and makes backups a whole lot easier :)
  10. We'll have to gather ideas what this is supposed to do, since the application was designed to be used by a single user.
  11. Relations would be nice! Multiple files per item won't be implemented though, since that would mean we'd have to redesign the entire application. Some sort of document binders / collections / groups would be possible, but we already have tags for that, and I don't like the idea of having multiple systems in place that essentially achieve the same thing.
totti4ever commented 3 years ago
  1. Tags, Correspondent, etc shown in overview

    Everything is shown on the card/in the table as much as the given space allows it. I'll have the Correspondent stand out a little more on large cards, if its available. Clickable properties: I suppose these should instantly apply a filter, which seems great to have.

Exactly, clicking them should add it to the filter or replace the filter. Best would be both of course (hovering on it, a little + appears, which adds it, otherwise the filter is replaced. But for ease of use, maybe let's start with adding :-)

==> #59

  1. Show document in the browser

    Yep, I just need to figure out where to put the buttons for that. The rest is already there.

I do have plenty of space there in tile mode and even more in the third mode?

==> #55

  1. Concerned person

    This is the correspondent of a document. This works in both ways.

  2. Direction of item

    It seems you want separate fields for sender and recipient.

I pulled 3 and 5 together as they should be treated together most probably. I would like to specify both sides, sender and recipient for every item. But, yeah - if I would filter on sender me, I actually had filtered on outgoing, so that would help

==> #62

  1. Syntax help

    The search is entirely different from upstream paperless. There's advanced syntax available, I just need to create the documentation for that. For now, you can look at whoosh.readthedocs.io/en/latest/querylang.html what the query language looks like.

Great to know, thanks!

  1. Corresponding person (detail of corresponding organization)

    Correspondents can be anything, a person, an institution, a mail box from where the document came from, etc.

Yeah, this might be too advanced for most users as one can simply add every person itself. I just kid of like this feature in Docspell as it gives you the opportunity to categorize your correspondents (like doctors, authority, etc). This can be reached through tags as well, though. So let's maybe drop this request for now :-)

  1. User-specific filename

    Do you mean setting a custom filename format? That's still in the code and will remain there. However, they are still generated from the date, title, correspondent and so on. Entirely custom filenames won't be implemented. The entire point of this software is that you don't have to care about how the documents are stored on disk.

That's totally fine. For myself I would say, that the primary purpose is to not care about the files. But it's always good to have them there in a readable form, either for exit strategy or for some direct access (Samba and so on).

  1. MariaDB/MySQL support

    Providing configuration options for that is easy, but making sure that it's working (now, and also in the future) is not. I'm running postgresql and can't make any promises about mysql. I'll think about it. As for now, even SQLite is reasonable for this kind of application and makes backups a whole lot easier :)

I have all my containers using a database write into one central MariaDB instance, which makes keeping an eye on what's in there quite easy. As well as backups. But it is indeed the case that more and more apps prefer a Postgres, maybe I should see whether I actually do have one which doesn't support it and switch otherwise.

  1. multiple files per item

    Relations would be nice! Multiple files per item won't be implemented though, since that would mean we'd have to redesign the entire application. Some sort of document binders / collections / groups would be possible, but we already have tags for that, and I don't like the idea of having multiple systems in place that essentially achieve the same thing.

Understood and agreed: But linking could be great. What stops me from using tags for this is that there would be a looot of tags then, which could be easier to handle if they were nested (see above :-) )

  1. nested tags or tag categories

    I've thought about this for myself and really like the idea. Have nested tags as in "bankstatement-account1" and "bankstatement-account2", filter by bankstatement to get all statements or by account1 to get just these. I'll add that to the roadmap.

I saw, you opened an own issue, I'll add more thoughts there, thanks!

==> #56

  1. Multi-user support as already mentioned in #52

    We'll have to gather ideas what this is supposed to do, since the application was designed to be used by a single user.

I totally agree that this is something nothing small and therefore should be thought about, I'll contribute to the corresponding ticket.

totti4ever commented 3 years ago

Plus: Do you already recognize duplicates using a checksum? This is also really helpful from my point of view!

jonaswinkler commented 3 years ago

That's totally fine. For myself I would say, that the primary purpose is to not care about the files. But it's always good to have them there in a readable form, either for exit strategy or for some direct access (Samba and so on).

Yep, I am very concerned about exit strategy. I'm not editing any documents in place and just put them in the media directory, and that's about it.

Thanks again!

Plus: Do you already recognize duplicates using a checksum? This is also really helpful from my point of view!

Yes, checksums are in place and prevent exact duplicates from being added twice. They are also used to verify that your document collection is still healthy from time to time (there's a sanity checker scheduled to run weekly).

totti4ever commented 3 years ago

added references to separate issues if existing - this can be therefore closed