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.
When using the built-in webserver in debug mode, the static files are
handled automatically. From the Django docs:
During development, if you use django.contrib.staticfiles, this will
be done automatically by runserver when DEBUG is set to True (see
django.contrib.staticfiles.views.serve()).
This method is grossly inefficient and probably insecure, so it is
unsuitable for production.
This means, when using a real webserver, it also has to serve the static
files, i.e. CSS and JavaScript. For that, one needs to run `./manage.py
collectstatic` first.
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.
issues found by shellcheck were:
```
$ shellcheck docker-entrypoint.sh
In docker-entrypoint.sh line 10:
if [[ ${USERMAP_UID} != ${USERMAP_ORIG_UID} || ${USERMAP_GID} != ${USERMAP_ORIG_GID} ]]; then
^-- SC2053: Quote the rhs of != in [[ ]] to prevent glob matching.
^-- SC2053: Quote the rhs of != in [[ ]] to prevent glob matching.
In docker-entrypoint.sh line 12:
groupmod -g ${USERMAP_GID} paperless
^-- SC2086: Double quote to prevent globbing and word splitting.
In docker-entrypoint.sh line 65:
if dpkg -s "$pkg" 2>&1 > /dev/null; then
^-- SC2069: The order of the 2>&1 and the redirect matters. The 2>&1 has to be last.
In docker-entrypoint.sh line 69:
if ! apt-cache show "$pkg" 2>&1 > /dev/null; then
^-- SC2069: The order of the 2>&1 and the redirect matters. The 2>&1 has to be last.
```
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.
