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.
The manifest URL (which is optional) will point to an XML file that
describes the command line, option file and environment options that
can be passed to an installer, to allow automated or non-interactive
deployment tools to figure out what info is required to run an
installer and how to pass it to it.
Requires SQL:
ALTER TABLE downloads_stackbuilderapp ADD COLUMN manifesturl character varying(500);
UPDATE downloads_stackbuilderapp SET manifesturl = '';
ALTER TABLE downloads_stackbuilderapp ALTER COLUMN manifesturl SET NOT NULL;
The "true dependencies" usign db relationships were too strict for
reality - multiple entries can have the same textid, and that's what
we need to depend on. Resolving it for platform is handled in the
StackBuilder client.
This update requires the following SQL to be run in the database:
DROP TABLE downloads_stackbuilderapp_dependencies;
ALTER TABLE downloads_stackbuilderapp ADD COLUMN txtdependencies varchar(1000) NOT NULL DEFAULT '';
ALTER TABLE downloads_stackbuilderapp ALTER COLUMN txtdependencies DROP DEFAULT;
Closes#167
"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.
