I have no idea why we do this in the database as some magic after we
call save(). I also have no idea why MySQL is seeming to think we want
type BIGINT UNSIGNED at the end of the
((2 * '+2' + '+1') - ( '-1' + 2 * '-2')) but it does.
Setting it to 2.0 or float(2) doesn't get the ORM to get this right, but
we are going to Decimal and making the 2 multiplier be of type Decimal
manages to make the ORM pull it's shit together and use something that
seems like we're okay with.
+1, -2 = 1 / 2 = -0.5 Score == True
Looks like it works.
UPDATE `symposion_reviews_proposalresult` SET `score` = CASE WHEN `symposion_reviews_proposalresult`.`vote_count` = 0 THEN '0' ELSE ((((2 * `symposion_reviews_proposalresult`.`plus_two`) + `symposion_reviews_proposalresult`.`plus_one`) - (`symposion_reviews_proposalresult`.`minus_one` + (2 * `symposion_reviews_proposalresult`.`minus_two`))) / (`symposion_reviews_proposalresult`.`vote_count` * 1)) END WHERE `symposion_reviews_proposalresult`.`id` = 1
Create a ephemeral dev container to facilitate testing of
populate_inventory. It can be created, tweeked in the admin interface,
files updated in admin's populate_inventory, then redeployed to deal
with those changes.
A branch based one will need to be created to so we can do this work
without polluting the master branch.
This improves the administrative workflow of deploying updated images to
the k8s cluster. Still tag latest however, as that's important to
old-workflow.
Would be good to block this and have it fail on a db migration so it
doesn't happen accidently, and make the deployer deal with it.
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
* Tweaks help_text to indicate that travel assistance is to Sydney
* Includes the required migration
This migration doesn't change the DB so it's safe to apply with the system live.
The current ordering is based on what appears to be a random ordering
that happens to correlate to the last time the paper was submitted or
updated. Oldest to most recent.
This changes it to submission order so ordering doesn't change and ID is
a static, making it easier to move through a list of papers. "I last
looked at 24, so 25 is assured to be the next one I want to look at.
There's the thought of updated papers being looked at and voted on, but
it does not seem to me that this is supported or possible. In general
one would look at their un-reviewed list, and go off it, which puts
updates out the window.
We can certainly order on other fields if desired, but this one makes
the most since to me.
This was removed somewhere in 1.8, which means this results in a
failure. If I understand correctly, this "name" is now derived from the
model name's __str__ or something like that.
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.
Link to the T&C and Code of conducts so people know what they are
accepting. Create this as a static link because i don't know how django
would accept this being something dynamic on the model.
This annoyingly creates a migration, but it's not a real change and
easier to accept it now than fight django forever.
This app is now python3 only so we must specify python3 when creating a
virtualenv. Yes this assumes that most people are using python2 as
default, most distros still ship this way.
