Those month filters are automatically generated based on the documents it finds in the database, so unless you've done something creative in hacking at the filtering system in the admin, it's likely that you've still got documents with
.created values in those dates. If you disable all other filters, and then select a month, do you get any documents?
The code that dictates that list is here: https://github.com/danielquinn/paperless/blob/master/src/documents/admin.py#L24-L31
@tfar theoretically it could but it doesn't at the moment. The problem isn't the login, but the consumption. There's currently no way to tell paperless when it's consuming a file that the file in question is for
User A or
User B. We'd have to refactor the consumer to watch multiple subdirectories, each with an associated user, and then use that relationship to attach the user to the document. It's a neat idea, but I'm sorry but I just don't have time for it.
@jat255 I'm sorry but I've been just overrun of late, trying to get another project off the ground while I'm also starting a new job. It's not left a lot of time for Paperless. I'll try to post notes on your PRs now.
Ok I've merged one of your PRs and commented on another. For the third one, that's a lot more than I have time for right now (have to cook dinner for the pregnant wife!) so I'm going to leave that for tomorrow.
There's a bug somewhere in the existing codebase that has one of the tests failing, so I'm going to try to iron that one out before I look at yours 'cause I think they may be relating to the same area (date guessing), but I promised @erikarvstedt that I'd release this weekend, so I'll definitely be digging around in your PR before that happens.
As far as I know, a "locked" database is usually the result of a filesystem problem. As the db is Sqlite here, my guess is that either (a) the permissions on the file (or parent directory?) are such that you can't write to it, or (b) the filesystem on which said file is mounted has gone away somehow. If this was a Windows system, you'd have to worry about the file being read at the same time as it's being written, but it looks like you're on a Linux box, so I'd have to guess either (a) or (b).
Sorry for the delay!
docker-compose upand see what comes out. I'm not sure how you installed it or how you're running it, but Paperless should definitely not be causing a reboot. In fact, I can't even think of how it would be causing one.
Hey @bauerj , sorry for the late reply, but thanks for the PR! This is an issue that regularly crops up and typically has to do with the (un)availability of inotify (network shares are notoriously common). Using --no-inotify (or a similar-sounding argument, I don't remember it exactly) will have the system revert to its old behaviour of a loop-poll.
@ngerakines a "correspondent" is juts a word Paperless uses to refer to "the other party" in a document. As the project was initially designed as a means for one person to log documents that had been sent to them by post, the correspondent was usually the person sending the letter to you. Otherwise, if it was a copy of something you sent to someone else, the correspondent would be the person/company/whatever you were sending the document to. If you feel this wasn't sufficiently clear, feel free to amend the docs! Pull requests are always welcome for documentation :-)
@kallangerard I believe so, yes, but there's a few things you have to be concerned about:
I think that's all you'd have to concern yourself with. If you do end up doing this up on a kubernetes cluster, I'd love to read the details of what you did to make it go. Please feel free to contribute some documentation and/or share a link to a blog/reddit post on the subject should you feel the urge to write down what you did.