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.
