All templates using {% csrf_token %} need to be rendered with a
RequestContext.
This reverts most of commit 58a08f2590
Also permit POST requests to /search/ -- these aren't relevant to the
site itself, but this used to be allowed before.
We want an API for this so they end up in the queue with all the other
requests, and get delivered to all our frontends without needing each node
to know about which frontends exist.
Previously we would only purge based on URLs, but some of the upcoming
new work requires arbitrary expression purging.
NOTE! Require the creation of the new SQL procecure in the database,
either from varnish.sql or varnish_local.sql depending on if it's prod
or dev.
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
Previously we required superuser, but that seems a bit excessive. We could
limit it based on specific groups, but for now, we'll allow all staff users.
Also make the help text show under the field itself for regular fields,
and in the left column only for textarea fields. This makes it possible
to use longer help texts without making things look really bad...
Now that we have more metadata, we can render this on the main page instead of
on the wiki. This commit copies all the text from the current wiki page, and
uses the new fields in the Version model to render the table on the same URL
as the reference was on before.
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 won't happen in production since we don't delete quotes, but it
happens on empty dev environments. It still renders a pretty ugly
frontpage, but it doesn't crash...
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.
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.
