| Age | Commit message (Collapse) | Author |
|---|
|
We did explicitly check for superuser permissions, so there was no way
to get in, but without the decorator we wouldn't get the redirect to the
login page.
|
|
Most of the system won't be using this, but it's still good to have for
completeness sake.
|
|
The regtime is always set to the extact time that an email was added. If
a different sendtime is specified, it's still good to be able to track
when something was added to the queue.
|
|
Sync up the "warning button" filtering with that of the alerts, which
means we don̈́'t alert for emails that aren't supposed to be sent yet.
This becomes more relevant as we also stop trying to send emails that
are set to be sent in the future, in preparation for upcoming
functionality to schedule email sending.
|
|
|
|
Also remove the save button since there is nothing to save, but keep the
delete button since we still want the ability to clear the queue.
|
|
|
|
This reverts commit d38c7e5237073e41abae530c4f93d0d3a976f681, as it is
no longer needed now that we have moved to the in-core JSONField.
|
|
Silence the deprecation warnings that otherwise happens on Django 3.2
about the deprecation of JSONField. This can be reverted once the full
migration to 3.2 is done, but since this is a cronjob that usually runs
every minute or two it generates an insane amount of warnings until
that point, so just shut it up.
|
|
|
|
Since all of our emails are, set it for all emails for now, but keep
flags around to make it possible to change in the future.
Hoepfully these headers will help decrease then number of out-of-office
emails received when sending things out.
|
|
Default is still going to be localhost on the default port, but it's now
possible to override this in local_settings.py by setting the value for
SMTPSERVER.
|
|
Normally this doesn't matter as all data in the table is very
short-lived, but it's ueful when debugging.
|
|
To make it easier to write plaintext emails, make sure the font used for
the email body is monospace, and do hard auto-wrapping at 72 characters.
In passing also make a couple of other fields like PEM keys for Trustly
use a monospace font (but of course not hard wrapping).
|
|
|
|
This adds a viewer and editor for the mailqueue to the dashboard,
superuser only.
While at it, expose time and subject directly in the queue to make it
easier to determine what is what.
Most of the time this is not going to matter because emails are
short-lived in the queue. But during development and definitely during
debugging, it can be quite useful.
Move the "parsed mail view" out of django admin and into the backend
view so we don't have to maintain it twice. There is very little use for
the admin view anymore, so it's OK to just show the raw data there.
|
|
Looks like this was broken in the python 3 migration, but missed since
it only affected cases where a single address was added, and not a list
of addresses. The only user of this was data-purge warnings.
|
|
|
|
2to3 doesn't do this automatically, probably because weird things can
happen if you had both. We know we didn't, so just do a straight
replacement.
|
|
Sibling imports should be prefixed with a period. Good idea in py2, will
eventually become required in py3, so another small step.
|
|
Python 2.6 introduced the better syntax, Python 3 removes the old one,
so one small step towards py3.
|
|
This can be a list (comma separated) of email addresses that will
receive a BCC of all emails about this invoice. This is similar to how
the treasurer address gets such a copy, but makes it possible to add
more than one address.
|
|
|
|
|
|
Mostly not important, but getting rid of the PIP warnings will help
catch errors in the future.
|
|
Surprisingly many of these were pure copy/paste errors from the same
source...
|
|
In an effort to close up with PEP8, we should use spaces for indent
rather than tabs... Time to update your editor config!
|
|
|
|
|
|
When sending an email to non-ascii names, the actual email address
should not be part of the encoded section. It should have a separate
section that's not encoded.
|
|
This introduces the function of the same name from the pgweb code base
(though it isn't identical, to be clear). This function is to be used
when rendering a text file into an email. There is a helper function
template_to_string() which is also added and can be used if a string
result is needed.
The primary different here is that the variables set in
util/context_processor:settings_context are included in the hash
automatically, so those settings do not need to be explicitly set by
the callers and the templates can expect them to be available.
Using that, this change also includes changes to move away from
hard-coded values like 'PostgreSQL Europe' in favor of using the
variables set in settings.py/local_settings.py in the text templates.
This will allow others to re-use the exisitng templates and not have
to develop and maintain their own going forward.
|
|
We only do very simple decoding, but even at this level it helps
a lot with debugging messages going out of the system.
|
|
This replaces our old custom migrations. NOTE! Since there are some
dependencies in these migrations, they need to be individually faked.
Since we want the django core apps to get upgraded anyway, the commands
that need to be run are:
python manage.py migrate auth --fake-initial
python manage.py migrate admin --fake-initial
python manage.py migrate contenttypes --fake-initial
python manage.py migrate --fake
Note: braintreepayments app not yet migrated
|
|
|
|
Instead of just using bare headers. Hopefully this will lower some spamscores,
and more importantly make things actually look better to receipients.
In passing, fix ability to use unicode characters in subjects.
|
|
This will BCC all manual invoice emails only. This is basically
all the emails generated except receipts that are generated for
invoices that have a processor set.
|
|
|
|
|
|
|
|
|
|
Makes it behave much nicer when there are issues sending, and doesn't
end up calling out to SMTP from within a regular web request.
|
|
Adds a function to call that will render a complete MIME message, and
write the resulting text to a database table.
Then there is a cron job that runs at regular intervals (every 5 mins or so)
and sends all the queued emails.
This brings in two important functions:
* The ability to "send" emails from regular web views without the risk of ending
up blocking on the SMTP server.
* The abilitty to "transactionally send email" - meaning that mail sen this way
will just disappear if the transaction (normally managed by django) that's open
when it was sent ends up rolling back. This prevents re-sending email over and
over again when some later step in the process fails.
|
