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.
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.
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.
The way these were handled they weren't really providing any value to
users, because a lot of sessions were registered and never run etc etc,
but did cause a lot of work for our moderators.
The general feature may return later in the form of "training providers"
or similar as part of the professional services section, but for now
there is no point in maintaining this data.
This updates various references to use NOTIFICATION_EMAIL, since that's
what we actually send the emails too.
Also change the moderators group to be 'pgweb moderators'.
This is where we set both the gitrev and the do_esi, both of which are
needed. This means that gitrev has been broken on static pages since
forever - oops.
The event display algorithm shows up to two non-badged events
that take place over the next three months. Subsequently, up to
seven minus |non-badged events| are returned.
The new look of the homepage is optimized for both desktop and
mobile views and is setup to help guide new and returning users
to appropriate PostgreSQL content.
Authors: Sarah Conway <sarah.conway@crunchydata.com> and me
The base HTML structure enables the responsiveness for the
website. In addition to the primary base template, the generic
page and form templates are also modernized.
Authors: Sarah Conway <sarah.conway@crunchydata.com> and me
render_to_response does not work on newer django, so it needs to be
replaced. And using a speicfic context actually overcomplicates things,
it's easier to just use a wrapper function. For those cases where we
don't need NavContext, just use render() (the new shortcut function from
django), which also removes the need to use RequestContext.
Previously we just used "is member of staff", but for better granuality
explicitly also check membership of groups. This introduces the new
group "varnish purgers" for that permission.
This lets us separate things like project news from other OSS and from
commercial postings, for example, allowing for people to subscribe to
different feeds with just the parts they are interested in.
Adds the "badged" flag to the Event model in order to distinguish
community badged events from other PostgreSQL oriented events.
Seven total events will be displayed on the homepage, with up to
four community events displayed. If there are no upcoming
community events then, then the header "Events" is shown.
The event submission interface allows a user to opt-in to
listing an event as a "community" event and provide an
explanation for moderators as to why the event should be
considered a community event.
Expands the list of News and Planet PostgreSQL blog entries to 10.
We'll use this to index some things in our own search engine without
exposing it to external sitemap parsers. Not from a security standpoint
of course, but something that will lead to it being possible to search
the devel docs again.
This one will validate that the url is under /accounts/, which is
the only part we are going to be excluding from caching once we
move the website to https-only.
Move manage.py up one step, set up a new wsgi.py file, and adjust
relative paths that refer to other directories for the new project
layout that we need to use in django 1.8.
The queue used for varnish purges has so few entries that it's really
not worth paying the management overhead for skytools/pgq. Instead we
can use a very simple local deamon using LISTEN/NOTIFY to fire them off.
Now include a proper nagios plugin in this package, so we can get rid
of the not-very-nice munin plugin currently used in the deployment.
