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).
If a HTML body is specified, the plaintext and html bodies will be sent
as a multipart/alternative MIME object.
Also teach it to add attachments with Content-ID and overriding the
Content-Disposition, to make it possible to reference images attached
using cid: type URLs.
This migration happened 10 years ago, so if someone hasn't updated their
records by now, they're not going to.
We still allow and special-case the migrated data in the database in
order not to delete history, but this removes the direct texts about it
which take up unnecessary space and confuse some people.
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.
Two of our international community sites have failed to resolve or reply
for a while now, so remove the links. Should they reappear we can always
add them back.
The French docs had one link in http and one in https as noted by
Lætitia. In passing I also adjusted the japanese to link to the https
version directly as one is available. The remaining one (Chinese) does
not appear to have a responding https server, so that one is left as
http.
There was a subtle difference between the migration and the
model itself, which was leading to a migration warning, even
though nothing about the help_text is persistent in an actual
database.
40d6891c had created a false illusion of working, which can
certainly be blamed on the patch author. That said, instead
of trying to work around what the standard Django filters
provide, it is more prudent to create a "URL checking"
function for the feature matrix descriptions. This can be
used both for the "featurelink" generation, as well as the
new check we make to get the stated goal of 40d6891c, i.e.
provide a clickable URL when that is the only content of a
feature description.
There are many feature matrix details pages that would have
just a plain URL that was not clickable, either due to someone
accessing a feature matrix details page directly, or due to an
old details pages with a description being converted to just a
link.
This ensures that such pages can have a clickable link to attempt
to create a better user experience. Doing so from the Django
template filters is a bit roundabout, but it does get the desired
effect.
This will make it possible to allow for links in longer
descriptions for particular features. This also adds some
help text describing how the feature matrix details field
works, as I remember I was originally caught by surprise that
one could provide a direct link to something.
We were already doing this for news, but for some reason neglected to do
so for events, which made for some pretty messed up formatting in the
archives now and then. We should treat news and events the same...
Minor updates to the specifics regarding how the committee membership is
managed and providing for a transistion period when the membership
changes.
Per direction of the CoC Committee, with Core approval.
The trigger is used for both UPDATE and DELETE, but in DELETE there is
no value in OLD.
Given that it only references the user_id field and this field cannot
change, we can just use OLD in both the UPDATE and DELETE case.
Back-patching in existing migration since it hasn't really been deployed
anywhere yet.
We don't do this for all pages, but specifically for policies that
already included the "Last update", it's friendly to have a link to the
full set of changes.
We still lave the "Last updated" field as manually updated, because we
don't want to update that one if we just fix a typo or similar, it
should be reserved for when we make acstual content updates to a policy.
This creates and uses a specific template tag to automate the creation
of the links (that can of course be used elsewhere as well if needed).
Previously we used a combination of optimistic concurrency control
(by DELETEing with both the id and the date included in the WHERE
clause) and REPEATABLE READ transactions. This would create
serialization conflicts when completely unnecessary. Since in this case
it doesn't matter if we happen to push the same thing twice, switch
completely to optimistic concurrency control. That gets rid of having to
deal with serialization issues.
This should not be possible if things are done through the appropriate
interfaces, and those interfaces are bug-free (right..). But really bad
things can probably happen if they don't, so put a monitor in place to
check for it.
This also adds a view in the db that shows all registered email
addresses and their accounts, regardless of if it's primary or secondary
address. This is used by the nagios check but can of course be useful to
manual checks as well.
It really shouldn't exist, but we clearly have cases where the community
auth plugin sets the email to NULL, so we need to handle that case when
looking for what to update.
This adds the concept of an apiurl to each site that uses community
authentication, that the main website server can make calls to and send
updates. This URL will receive POSTs from the main website when a user
account that has been used on this site gets updated, and can then
optionally update it's local entries with it (the django plugin sample
is updated to handle this fully).
Updates are only sent for users that have a history of having logged
into the specific site -- this way we avoid braodcasting user
information to sites requiring specific constent that the user hasn't
given, and also decreases the amount of updates that have to be sent.
Updates are queued by the system in a table and using listen/notify a
daemon that's running picks up what needs to be updated and posts it to
the endpoints. If this daemon is not running, obviously nothing gets
sent.
Updates are tracked using triggers in the database which push
information into this queue.
This allows each account to have more than one email address, of which
one is primary. Adding more addresses will trigger an email with a
verification link (of course). The field previously known as "email" is
now changed to be "primary email".
Change the profile form to allow freely changing between the added
addresses which one is the primary. Remove the functionality to directly
change the primary email -- instead one has to add a new address first
and then change to that one, which simplifies several things in the
handling.
It's useful to be able to directly get at the user record that was
returned instead of having to re-query it from the database. Since
nothing was previously returned, this is not backwards incompatible.
This makes it possible to limit which organisations can use specific
tags in news, and verify those as news is submitted. Administrators can,
as always, override.
In passing also add a sortkey field to newstags to make them, well,
sortable and include urlname in the json output.
