Shouldnt be neccessary, template loader should be finding the template provided by the installed app.
but it's not, and I want rego to go live today, so here we go.
One day when things are nice this commit can be reverted and I will be crying a little less on the inside.
I think this removes most references to "hobart", "pycon", and "2017"
There are still some references to some images that we don't have a
replacement for.
Only want to show this once - not once per invoice.
It's not something most people will need to use so it doesn't need to
be a button. Restyle it to be a link
An errant ``{% if pending %}`` meant that we were only showing paid
and cancelled invoices - and the ability to buy new products - if
there was currently a pending invoice.
This change remove the errant check and allows for anyone with a paid
invoice to inspect it; or to add products.
NB: all the proposal sections for the miniconfs here are set to open
on 2017-11-01. To make them available sooner, visit
/admin/symposion_proposals/proposalsection and change the start date.
* Remove the outdated compiled javascript once again
* Update the sitetree_header template to use more detail.
The extra detail here is taken from the menu_bootstrap3.html template
distributed with django-sitetree
Flagging this as a review table means we get sorting, pagination, and
search. Much awesome, esp when we want to do this like "show me all
the ones that haven't been notified yet"
* This reference was added in the very distant past
* But jquery.history.js itself has never been in the repo
* pyconau-2017 team resolved the dilemma but dropping
jquery.history.js into the repo
* But as near as I can tell, this does nothing except in obsolete
older browsers. The fact that it's been broken ever since it was
"added" is highly suggestive of it never having ever been used or
needed
* So, trim the fat. It's possible that this might break an older
browser that needs the functionality jquery.history.js provides -
except that such a browser would *already* be broken because
jquery.history.js has never actually been around to be used.
* If we ever do need this functionality, we can revert this
change.. and then we'd have to drop in jquery.history.js. In that
circumstance,
https://github.com/pyconau2017/symposion/commit/34bc7c0 may be of interest.
* Adds an env variable to .env to turn on dev mode
* Uses the inbuilt django auth rather than saml when in dev mode
* For laziness, re-uses the admin login form for the non-admin login
make_dev_container now comes up ready to be logged into by any
user. No non-admin users are preconfigured; but you can add one at
http://localhost:28000/admin/auth/user/add/, log out, and then hit
http://localhost:28000/ to log in as the new user.
Editing a miniconf, on save, the code looks in settings for
ADMIN_USERNAMES, and as it does not exist, we stack-trace and 502 to the
user.
Add the attribute to settings.py
So django keeps strict synchronization between its code and migrations
so that it can help generating new migrations. These are the additional
suggested migrations. A lot of these are a null effect, some are things
like transforming an unsigned integer to a signed integer. So not super
urgent on a small scale, but worth doing to keep django happy.
We need to have people who are submitting a miniconf proposal agree to
releasing the material. The easiest way to do this is to just make it a
proposal like the other two types. We don't have audience type for
miniconf, instead of deleting it just have a default - it's easier.
WARNING: This requires a real migration to be performed before use.
Update the recording and materials release to say Linux Australia, not
Pycon Australia. This generates a migration because the model text has
change - but also because in the 0001_initial migration it appears that
this help text is stored as a byte string.
This is a bit weird, but realistically running this migration is not
going to cause us any problems so just add it so we don't end up
fighting django along the way.
DEBUG is something that should never be turned in on prod. As such,
lets be extremely specific on what we expect to process.
As we'll be taking this in from the environment, it's ensured we will
get a string. So we'll always get and only handle this in string
form. If it's anything else, it's an operational error and we bail.
(Note: bool('0') is truthy, so we make sure we leverge our string -> int
-> bool every time, so corectness can be noticed if it is not)
