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.
Caused an exception when somebody tried to upload an SSH key where the
*key type* contains non-ascii (this would normally be things like
"ssh-rsa", and there are definitely no legit key types outside the ascii
range, but we still shouldn't crash)
In essence, a release is supported until its 5 year anniversary, and
will receive one additional set of fixes after that. This is inline
with what we are currently doing, but should help make it more clear.
In particular, reject ssh-dss keys here. They don't work anymore since
an upgrade, for security reasons, but there was not really a way for the
user to know why. With this they will at least know if when they try to
save or change the keys.
This finally moves the patches into the db, which makes it a lot easier
to filter patches in the views.
It also adds the new way of categorising patches, which is assigning
them a CVSSv3 score.
For now, there are no public views to this, and the old static pages
remain. This is so we can backfill all existing security patches before
we make it public.
Unfortunately, we'll send one email for each m2m field, instead of
collecting them to a single one. That's because there is no signal
delivered at the end of them all, there will be one sent for each field.
Luckily we don't have a lot of m2m fields at this point, and no model
has more than one, so at this point that part is not a problem.
It also means that if a regular field *and* an m2m field is changed,
then we will get two notifications.
Finally, enable these notifications for the Organisation fields, meaning
we will get a notification when an Organisation changes managers, which
was not working before.
1. ForeignKey with unique -> OneToOneField
2. IPAddressField -> GenericIPAddressField
3. Fix fields with default=datetime.now() which gives server start time,
not the insert time (clearly this default was never used, and the
field was always explicitly set, but it should still not be incorrectly
defined)
We were already using signals for everything except delete, and even
in our old version of django the delete signal exists (it didn't exist
when this code was first written).
Django doesn't really like models to be OOP like this, so keeping PgModel
would cause issues with upcoming changes in django 1.8. Using simple functions
is easier, and the actual functionality is replicated straight off.
This allows us to specify both beta and rc versions.
Requires SQL:
ALTER TABLE core_version RENAME COLUMN beta TO testing;
ALTER TABLE core_version ALTER COLUMN testing TYPE integer USING CASE WHEN testing THEN 2 ELSE 0 END;
Instead of having to update this list manually in multiple places when
releasing new versions, just take the information out of the database
where it has to be anyway.
Fixes#90Closes#93
Also make the code automatically pick up wich PDF files exist in the
static checkout, and auto-detect their size, both A4 and US sizes. This
removes yet one more manual step, yay!
Fixes#163
This was originally not done because we had a lot of old legacy data
that didn't have entries in both tables. This is no longer the case,
and the docloads script already enforced that it couldn't happen again.
Requires SQL:
ALTER TABLE core_version ADD CONSTRAINT version_unique_tree UNIQUE(tree);
ALTER TABLE docs ADD CONSTRAINT docs_version_fkey FOREIGN KEY (version) REFERENCES core_version(tree);
This replaces the previous ugly hack where beta versions had a negative number
as latestminor, giving a much cleaner model.
Requires SQL:
ALTER TABLE core_version ADD COLUMN beta boolean NOT NULL DEFAULT 'f';
ALTER TABLE core_version ALTER COLUMN beta DROP DEFAULT;
(Yes, we really need to move to something that can do automatic migrations)
Notices entered will be sent to the organisations email address - so there
needs to be one (if not, the notification field doesn't show up).
Notifications also go in the database, and show up on each object so you
can see the previous history of it, and get emailed to the slaves list.
Finally, it's possible to reject-with-notification, in which case the
notification is sent off to the user and after that the object is deleted.
The notification history stays in the database, but is not linked anywhere
(but can be viewed from the admin interface on that model directly).
Unfortunately, this seems to cause double notifications to the slaves list,
but we'll have to live with that for now.
Closes#137
This requires the following to be run on all developer installations:
alter table core_version add column "firstreldate" date NOT NULL default current_date;
alter table core_version add column "eoldate" date NOT NULL default current_date;
alter table core_version alter column "firstreldate" drop default;
alter table core_version alter column "eoldate" drop default;
This makes it possible to figure out when the docs were actually
loaded, since developer docs don't carry a version number. This is
actually going to be the docs *load* timestamp, and not build timestamp,
but they should be close enough together that it shouldn't matter.
Fixes#108
This allows all models inherited from PgModel to specify which
URLs to purge by either setting a field or defining a function
called purge_urls, at which point they will be purged whenever
the save signal is fired.
Also implements a form under /admin/purge/ that allows for manual
purging. This should probably be extended in the future to show
the status of the pgq slaves, but that will come later.
Includes a SQL function that posts the expires to a pgq queue. For
a local deployment, this can be replaced with a simple void function
to turn off varnish purging.
"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.
