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.
