Fix qhasuery modification so that conditions are combined
Borrowed from the pyconau-2017 fork
To explain the impact of this - without this patch, if a user has their invoice refunded, they are able to buy a new ticket; but t-shirts, dinner tickets and so on do not become available to them again because they are listed has already been in a cart for them.
Applying the patch now correctly checks to see if they currently have a ticket.
From 731eee0a4c42a5013ee312b1ff50548e4d89a2ff Mon Sep 17 00:00:00 2001 From: Richard Jones <r1chardj0n3s@gmail.com> Date: Sun, 4 Jun 2017 13:22:34 +1000 Subject: [PATCH] Fix query modification so that conditions are combined
Previously it was checking if the user has a product from the category in a cart, and if there is no cart that is released (refunded). Not *if the user has a product in a cart that is not released*.
This patch combines them. In the absence of a __ne operation in the joining syntax, a double equality check is needed.
Signed-off-by: Richard Jones <r1chardj0n3s@gmail.com>
This creates more intermediates, but moves those that are less likely to change to the top of the file. In theory this will produce faster builds on a developer's machine as they won't need to apt-get update every time.
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.
Finish adding models/forms/admin for new miniconfs
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.
Set review-table class to get goodness on notification page
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
* Adds a laptop-mode-env file which docker can read env variables from * Adds a Dockerfile.makemigrations; mostly identical to the main Dockerfile. Important difference: instead of the source being copied into the docker image at build time, it's mounted from the local machine at run time. * Adds a makemigrations shell script which builds an imagine using the Dockefile.makemigrations and then uses it to run makemigrations * Because the source is mounted from the local machine, any new migrations created are dumped in the developer's git checkout ready for adding to git.
This follows from investigations in https://rt.lca2018.org/Ticket/Display.html?id=283&results=eac0bd3c49f782d054f87d6b160ca36b; in short, it seems that because this very long and complex method creates several different objects at differnt times, the DB has been getting out of sync; there are more votes recorded then there are reviews, becuase the table that stores the vote count is updated before the table that stores the vote and review information
This change is intended to make this operation (and the other operations that the revew_detail handler performs) atomic, to prevent things getting further out of step. It does *not* fix the existing incosistency.
review_delete has been atomicified as well as it likely needs the same treatment, but this has not been examined in detail.
File "/app/symposion_app/vendor/symposion/reviews/views.py", line 230, in review_random_proposal proposals = proposals[:(len(proposals) + 1) / 2] TypeError: slice indices must be integers or None or have an __index__ method
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.
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.
It's really annoying when you are adding a proposal and you hit tab and end up on the link to the Hack website. There's no need for this and at least on newer browsers we can pretty easily skip the links for tab.
Unfortunately because this is model text it generates migrations. As we know these migrations don't actually do anything, so they are annoying but not actually harmful.
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.
Add release materials check boxes to miniconf proposal
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.