About page goes from 10min to 30min (short cache to rotate the
quotes).
Search results go from 15min to 30 min.
Dynamic CSS goes from 6 hours to 48 hours, since we use cache busting
URLs everywhere these days, and on average they change very seldom.
When a moderation notice was sent without making any actual state
changse (so not approving, rejecting or returning), the notice would
only be sent to the submitter, and not to the moderators. Which
obviously can lead to some confusion. So make sure that it's always sent
there as well, and the message clearly states that it was just a
comment.
In particular, highlight that an organisation is not needed to
participate on lists, send bug reports etc. Caused by the number of
people who apparently get this wrong previously.
* Get rid of the django_markwhat dependency, and implement our own
classes to get more control. In passing also remove django-markdown,
because we never used that.
* Instead of trying to clean markdown with regexps, use the bleach
library (NEW DEPENDENCY) with special whitelisting of allowed tags
based off standard markdown. This means that one can input links or
formatting in HTML if one prefers, as long as it renders to the same
subset of tags that markdown allows.
* Replace javascript based client side preview with an actual call to a
preview URL that renders the exact result using the same function,
since the use of showdown on the client was increasingly starting to
differ from the server, and since that cannot be kept secure the same
way. Rewrite the client side javascript to work better with the now
longer interval between updates of the preview.
Long in planning, but never got around to it.
Suggestion to use bleach for escaping from David Fetter.
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.
Change the subject to use the title of the object instead of the id, and
include a link to the moderation page. There's surely more to be done,
but this is a decent start.
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.
Since we can purge based on the md5 hash of a template name, expose this
in the purge dialog so one doesn't have to manually calculate the hash
to use it.
Two-moderator items require only one moderator to be rejected or to be
sent back for more editing. In that case, don't log None as the other
moderator.
This was never used. And it was probably good that it wasn't, because if
it had it would've included both two copies of bootstrap in the page,
and also the bootstrap css map (as part of the css, and not as the map).
The docs pages these days use the same base stylesheet as the rest of
the site.
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.
Instead of tracking one single (non-verified!) email address for
organisations only to send notificationsn to, send the notifications to
all managers. This is relevant because all managers are in a position to
act upon them (and for example fix a posting).
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.
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).
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.
This is the place to load them to make sure they always load. This means
we can also now remove a hardcoded special varnish purging in the CVE
crawler script, because all saves including those from cron jobs will
now fire the signals and thus the automatic varnish purges.
With the new django, alerts are raised for everything with status 500,
not juse exceptions. This put a light on a number of places where we
were returning 500 server error code for things that are not actually
server errors. Some should be a regular 200 ok with an error message,
and others should be a permissions error.
This is primarily to enable the "make STYLE=website html" build
option of the PostgreSQL docs, as the pgweb docs page uses
the "base.css" file to render the documentation. By updating the
dynamic doc.css generation file, we can allow the builders of the
documentation to better preview what their documentation will look
like when it is loaded onto the website.
Presently, the dynamic "docs.css" is unused in pgweb or the core
project, and as those are the two biggest consumers of the
documentation styles, this is an apparent safe vector to make this
change.
This creates a consolidated area to reference all of the notes from
previous releases of PostgreSQL, as current releases only keep the
the notes for that specific major release of PostgreSQL.
