At this point, we set the field to PROTECTED and dont' allow the
deletion at all. In the future we might want to allow a set null
operation, but for now we require the users to contact webmaster@ to
handle that, so we keep it under control.
The addition of the fieldsets did not account for the fields
themselves from being removed from the new organisation form.
The OrganisationForm now removes the appropriate fieldset when
the fields are not available in this form.
This will trigger the same reset-your-password email as a user initiated
one, but it'll cut out one step and be a bit more user friendly...
Also, if this is done with an OAuth connected account, it will be
converted into a regular one (something we don't allow the end user to
do, for support reasons)
This also adds an entry to the user editor in the admin view that shows
if the user *is* an oauth user or not, or if they might have an old
"unmigrated" password.
This allows organisation managers to add more than one email address to
an organisation, and use this for sending news from. Sending news is the
only thing that the email field is used for at this point. Adding an
email will trigger a validation email sent to the address with a token
to confirm it, so that we can actually trust the emails.
Remove the previous registered emails on organisations. These addresses
were never validated and thus cannot really be trusted, so it's better
to remove them cleanly than to migrate them into the new system and be
uncertain.
Finally, in passing, remove the phone field on organisations. We've
never used that for anything and there's not really any point in
collecting the data.
When a news article is approved, it gets delivered as an email to the
pgsql-announce mailinglist. It will render the markdown of the news
article into a HTML part of the email, and include the markdown raw as
the text part (for those unable or unwilling to read html mail).
For each organisation, a mail template can be specified. Initially only
two templates are supported, one "default" and one "pgproject" which is
for official project news. The intention is *not* to provide generic
templates, but we may want to extend this to certain related projects in
the future *maybe* (such as regional NPOs).
These templates are stored in templates/news/mail/*.html, and for each
template *all* images found in templates/news/mail/img.<template>/ will
be attached to the email. "Conditional image inclusion" currently not
supported.
To do CSS inlining on top of the markdown output, module pynliner is now
required (available in the python3-pynliner package on Debian).
A testing script is added as news_send_email.py in order to easier test
out templates. This is *not* intended for production sending, so it will
for example send unmoderated news. By sending, it adds it to the
outgoing mailqueue in the system, so unless the cronjob is set up to
send, nothing will happen until that is run manually.
Support is included for tagged delivery using pglister, by directly
mapping NewsTags to pglister tags.
While at it, update the moderation preview forms to preview news items
using the HTML template for the email (while leaving other types of
items previewing without a particular stylesheet).
This includes a number of new features:
* Move some moderation functionality into shared places, so we don't
keep re-inventing the wheel.
* Implement three-state moderation, where the submitter can edit their
item and then explicitly say "i'm done, please moderate this now".
This is currently only implemented for News, but done in a reusable
way.
* Move moderation workflow to it's own set of URLs instead of
overloading it on the general admin interface. Admin interface remains
for editing things, but these are now separated out into separate
things.
* Do proper stylesheet clearing for moderation of markdown fields, using
a dynamic sandboxed iframe, so it's not ruined by the /admin/ css.
* Move moderation email notification into dedicated moderation code,
thereby simplifying the admin subclassing we did which was in some
places quite fragile.
* Reset date of news postings to the date of their approval, when
approved. This avoids some annoying ordering issues.
The way signals are sent for many2many apparently changed completely
between the python2 and python3 versions of the same Django version,
which broke the way we did this before. And it was always a bit of a
hack...
Instead, reimplement notifications in the simple_form handler. This now
also consolidates regular field notificationss and many2many
notifications in a much cleaner way.
This will, however, *only* have an effect on changes made through
simple_form. Luckily that's the most common way we handle forms, with
the exception being /admin/. So leave the old code in place to handle
the changes through /admin/, as well as the deletion of objects.
In the end the only thing lost is the ability to get m2m differences
when an admin makes changes, and that's the least important of all
notification. And as a bonus, the regular change notifications and in
particular "new item" notifications look a lot nicer.
We don't want two different accounts to exist with the same email
address only differing in case. This had already happened for a few
which have been manually fixed, since it turns out we only enforced the
rule on new account creation, not when accounts changed email address or
when they were created using oauth. Also add database level constraints to
make sure this cannot happen again if some codepath is missed.
"submitter", thus making it possible for a single person to manage
multiple organisations, as well as for a single organisation to have
multiple different manages.
Re-hook events and news items to use organisation of the submitter
instead of the user who did the submission. (product listings already
did this)
part of the core, since it seems like it could be useful for other
kinds of objects as well in the future, but for now only the
software catalogue uses it.
