It either wraps or it does not depending on how it is set in the config.
There is no point in determining it again for each document. Instead we
simply store it as a member variable the first time we check.
This is a lot cleaner than trying to hack around whether or not the
FinancialYearFilter is part of the available filters. This way it will
show up if there are result for it and the dates are set, and it will
not if any of those conditions is not set.
Originally we used SHARED secret both for email and for the API. That
was a bad idea, and now that we're only using this value for one case,
I've renamed it to reflect its actual use.
After tinkering with this for about 2 hours, I'm reasonably sure this
ever worked. This feature was added by me in haste and poked by by the
occasional contributor, and it suffered from neglect.
* Removed the requirement for signature generation in favour of simply
requiring BasicAuth or a valid session id.
* Fixed a number of bugs in the form itself that would have ensured that
the form never accepted anything.
* Documented it all properly so now (hopefully) people will have less
trouble figuring it out in the future.
Especially when first setting up the configuration for consuming
documents from emails it makes sense to quickly test the changes. Having
to wait for 10 minutes is not acceptable.
There are two ways around it that come to my mind: the simple approach
is to always fetch the emails when Paperless first starts. This way the
fetching of emails can be tested straight away.
The alternative would be to have a configuration option that allows to
set the interval in which emails are checked. The user could then reduce
it to test the setup and increase it again later on. This seems
needlessly complicated though, so fetching at startup it is.
The `SessionOrBasicAuthMixin` and `StandardPagination` classes were
living in the documents app and I needed them in the new `reminders`
app, so this commit breaks them out of `documents` and puts them in the
central `paperless` app instead.
I've broken out the OCR-specific code from the consumers and dumped it
all into its own app, `paperless_tesseract`. This new app should serve
as a sample of how to create one's own consumer for different file
types.
Documentation for how to do this isn't ready yet, but for the impatient:
* Create a new app
* containing a `parsers.py` for your parser modelled after
`paperless_tesseract.parsers.RasterisedDocumentParser`
* containing a `signals.py` with a handler moddelled after
`paperless_tesseract.signals.ConsumerDeclaration`
* connect the signal handler to
`documents.signals.document_consumer_declaration` in
`your_app.apps`
* Install the app into Paperless by declaring
`PAPERLESS_INSTALLED_APPS=your_app`. Additional apps should be
separated with commas.
* Restart the consumer
This was a weird bug to run into. Basically I changed a CharField into
a ForeignKey field and ran `makemigrations` to get the job done.
However, rather than doing a `RemoveField` and an `AddField`, migrations
created a single `AlterField` which worked just fine in SQLite, but blew
up in PostgreSQL with:
psycopg2.ProgrammingError: operator class "varchar_pattern_ops" does
not accept data type integer
The fix was to rewrite the single migration into the two separate steps.
MariaDB/MySQL doesn't handle indexes on TextFields well and for some
reason, Django's migrations opts to blow up rather than handle this in a
more user-friendly way. The fix here isn't ideal, but should be
sufficient should anyone try to use Paperless with MySQL.
This change includes a filthy hack around how Django handles
change_list_results.html -- I'm not thrilled with it, but it's as
elegant as I could come up with. I'm happy to field alternative ideas.
More details can be found in `documents/templatetags/hacks.py`
Specifically, this merge includes a significant facelift to the
documents listing page, moving away from the tabular layout and toward a
tileset look. I tried fiddling with the colours, but I just don't have
any skills in that area, so we're all stuck with Django'd default
colours until someone with an eye for colour can submit a better CSS.
