There was a subtle difference between the migration and the
model itself, which was leading to a migration warning, even
though nothing about the help_text is persistent in an actual
database.
40d6891c had created a false illusion of working, which can
certainly be blamed on the patch author. That said, instead
of trying to work around what the standard Django filters
provide, it is more prudent to create a "URL checking"
function for the feature matrix descriptions. This can be
used both for the "featurelink" generation, as well as the
new check we make to get the stated goal of 40d6891c, i.e.
provide a clickable URL when that is the only content of a
feature description.
This will make it possible to allow for links in longer
descriptions for particular features. This also adds some
help text describing how the feature matrix details field
works, as I remember I was originally caught by surprise that
one could provide a direct link to something.
The feature matrix is now modified to be helpful for newer users.
Entries now go from neweset version to oldest, as well as
displaying all entries by default.
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.
Requires manual sql to be run on all installations:
BEGIN;
ALTER TABLE featurematrix_feature ADD COLUMN v92 int;
UPDATE featurematrix_feature SET v92=v91;
ALTER TABLE featurematrix_feature ALTER COLUMN v92 SET NOT NULL;
COMMIT;
Turn the feature matrix fields into their own class and add a paramter
for visible_default to it. Turning this off will hide them from view.
In the future this could be expanded to make it dynamic, but for now let's
just stick to being able to statically hide them.
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.
