This includes a number of new features:
* Move some moderation functionality into shared places, so we don't
keep re-inventing the wheel.
* Implement three-state moderation, where the submitter can edit their
item and then explicitly say "i'm done, please moderate this now".
This is currently only implemented for News, but done in a reusable
way.
* Move moderation workflow to it's own set of URLs instead of
overloading it on the general admin interface. Admin interface remains
for editing things, but these are now separated out into separate
things.
* Do proper stylesheet clearing for moderation of markdown fields, using
a dynamic sandboxed iframe, so it's not ruined by the /admin/ css.
* Move moderation email notification into dedicated moderation code,
thereby simplifying the admin subclassing we did which was in some
places quite fragile.
* Reset date of news postings to the date of their approval, when
approved. This avoids some annoying ordering issues.
With the new django, alerts are raised for everything with status 500,
not juse exceptions. This put a light on a number of places where we
were returning 500 server error code for things that are not actually
server errors. Some should be a regular 200 ok with an error message,
and others should be a permissions error.
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 do this by always spidering every repo rpm available (since the ftp
server doesn't know about supported versions), and then filtering which
versions are shown in the dropdown instead. Given the small number of
versions of either kind, this doesn't make a material difference in the
size of the files anyway.
Using the crawled data, propulate dropdown boxes with versions and
platforms, to be able to show simpler instructions of exactly which
commands to use to install using the yum repository.
The ftp server can then submit a list (and structure) of which platforms
are supported for yum downloads, which can then later (in a separate
commit) be used to generate a nicer download for yum repo rpms.
This change properly handles symlinks by expanding any it finds in the path
and issuing a redirect to the canonical location.
Whilst we're here, display links as such on the pages, sort directory listings
so the parent link is always at the top, and avoid unnecessary redirects caused
by missing /'s on URLs.
This one will validate that the url is under /accounts/, which is
the only part we are going to be excluding from caching once we
move the website to https-only.
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
Previously this had to be rsynced outside of the website. By allowing the
upload here, and automatically purging the data from varnish, we will reach
"almost instant" updates of the ftp site structure on the web.
Still leaves the old templates around in case we want to go back on this,
as well as keeps the pure redirector service around so accesses from
things like stackbuilder don't stop working.
on the ftp server, instead of crawling the directoreis directly. This
removes the requirement to sync almost 10Gb worth of ftp site onto the
web server...
The pickle file for this is currently around 1Mb, so it's not a huge
burden on the server. If it grows larger in the future, we may want to
re-think this and split it up, or put it in a database format or something
like that.
