This includes most models that just contain "metadata" as well as the
complete feature matrix (because it's useful).
Also add a script to refresh the contents of the fixtures. Still has to
be run manually, but mayeb it helps us keep it slightly more up to date.
pgweb is no longer the master of this information, so add a tool to make
it sync it from the archives server.
Any changes made locally will be overwritten by this tool except the
sortkey field on groups which is local. For now.
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.
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 has been in standard python since 2.6, and we don't really care
about supporting anything older than that (even our old and soon to
be upgraded environments use 2.7)
This was plain broken for things like nomail and digest, but even with
the right syntax it probably did not work right together with the fact
that we require confirmation for subscriptions.
Issue spotted by Amir Rohan, fix suggested by Alvaro Herrera, (broken) code by me
Import the code from the PostgreSQL Europe website to handle this, since it's
well proven by now.
Any points that send email now just write them to the database using the
functions in queuedmail.util. This means we can now submit notification
emails and such things within transactions and have them properly roll bcak
if something goes wrong (so no more incorrect notifications when there is
a database error).
These emails are picked up by a cronjob that runs frequently (typically
once per minute or once every 2 minutes) that submits them to the local
mailserver. By doing it out of line, this gives us a much better way of
dealing with cases where mail delivery is really slow.
The submission from the cronjob is now done with smtp to localhost instead
of opening a pipe to the sendmail command - though this should have no
major effects on anything.
This also removes the setting SUPPRESS_NOTIFICATIONS, as no notifications
are actually ever sent unless the cronjob is run. On development systems
they will just go into the queuedmail table, and can be deleted from there.
This is used so we can reference the group as a negative id number from
a template, which is the standard way we separate it from lists when
included in the same dropdowns.
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.
Each module now contains a struct.py file that will return all
the URLs that it can generate (yes, this is a small break of the
abstraction of url.py, but we've broken that elsewhere as well),
and also which search-engine-weight (0.1-1.0) that this URL should
be given.
