- Use the first template in the system
- If there's no template, use /tickets/review as it at least gives
- people an overview of what they've paid for and warns them of
missing categories
* The qrcode contains no information that isn't in the URL you used to
access the code, so information is being leaked
* Allowing unauthenicated access lets people see the image in their
mail client
Not ideal. Let's revert this later and think of something better next
year - perhaps spending some more time researching best practices on
images in email..
* Switch to showing the PNG version by default, as this reflects what
will actually be rendered and sent to the printer
* Include the greyscale filter
* Include the twemoji font we'll use for rendering the badges
* The slot object updates its name every time it is saved
* But sometimes its slotrooms are changed underneath it, and so the
name can become out of date
* This method is a simple way of updating the names for all the slots
This allows for the boarding functionality to be safely tested with
just a subset of users first. Once you're ready to go live Fur Reals,
just delete the group and all users will become eligible.
Shows summary of all attendees with a paid ticket, including
boarding_pass status.
Currently, regidesk allows staff with the requisite permission the
ability to view the checkin status of attendees, and email the user
their boarding pass email.
Included is a view for the user to retrieve their own QR code (in case
they got the plain-text version of the email, they can use this to
download an image to their phone for faster checkin)
* A TimeOrStockLimit limit can apply a limit to a whole category, or
to specific products
* This report was only counting the products directly listed
* Take advantage of the new all_products property to include the
products indirectly listed as well as those directly listed
It's common to need to query the fill list of products covered by a
Flag - whether directly, or by being in an included category.
Add an all_products property which does this.
* Add a greyscale filter to text for more accurate preview
* Always default to SVG preview as it's the most accurate (cairo
doesn't do a great job of handling custom fonts when it converts to
png/pdf)
* Always use roboto font.
* Undo some of the debugging done early in this series of patches
* Add ability for a user to preview their own badge
* Add a template for the LCA2018 badge
* lca2018 has a situation where we have multiple slots starting at the
same time, but ending at different times
* The headers of the timetable grid are sorted by room sort order
* In sqlite at least, ordering by start,order seems to implicitly
resolve duplicate start times by looking at the other sort fields
first, and will only sort on order if all other fields are identical
* This results in the slot that ends first going in column 1, which
gets out of sync with the room listed in the header
* I can't figure out how to solve this in the database, so...
* Force the slots to be sorted by room order.
* Then, for each start_time, select out slots starting at that time
and operate on them
* This both gets the slots in the right order *and* keeps multi-room
slots with the right colspan. Yay!
* It's possible that this wouldn't be needed on some DBs which might
do the sorting differently.
In many parts of the schedule there are multiple slots with the same
start/end times, and it can be hard to find the one you want to edit.
Make this slightly simpler by listing the room names in the admin list.
* Whether a Flag is disable-if-false or enable-if-true is a very
important detail
* But one that's easy to get wrong
* And it's hard to spot problems without inspecting every single flag
This change adds the Condition into the various admin list views, so
that it's easier to scan them all for problems and look for inconsistencies.
* Old implementation needs to see exactly the same rooms in exactly
the same order every time it loads new data, otherwise it will
create a duplicate entry for the room that differs only in display
order.
* New implementation ignores the display order when checking to see
if the room already exists.
- This has the effect of bouncing people to the login page if they're
unauthenticated, rather than returning a 502 because 'home' doesn't
exist.
- If they're authenticated but don't have a speaker profile, send them
to the speaker profile create page rather than just to the
dashboard.
Closes#26
"Next" is green, indicating that it's the default path, the way
forward. "Back" is available but blue.
For extra consistency, the initial "Get ticket" button is now also a btn-success
Let's say you've just installed symposion for the first time, and
you're running the intial `./manage.py migrate`
In that circumstance, there isn't an auth_group table. Naturally this
means you get Some Errors when trying to look for a particular group.
This change handles that error and drives on.
Also update vendored_requirements to make sure we pull this in.
subrepo:
subdir: "vendor/registripe"
merged: "9fc3645"
upstream:
origin: "git@gitlab.com:tchaypo/registrasion-stripe.git"
branch: "lca2018"
commit: "9fc3645"
git-subrepo:
version: "0.3.1"
origin: "???"
commit: "???"
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 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.
Resolves:
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
* 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.
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.
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.
