symposion_app Changelog /vendor/symposion/reviews/views.py

Changelog - /vendor/symposion/reviews/views.py @ 37a02c170453 - showing 9 out of 9 revisions

Joel Addison	37a02c170453	5 years ago	Update review pages Update review pages Show the same options for reviews on the dashboard and on review screens. Add title to all pages within the review section.
Joel Addison	94f8837288a6	5 years ago	Allow admin to manage own proposals Allow admin to manage own proposals Do not block admins from changing votes, result or messaging on their own proposals.
Joel Addison	87ecc83314c6	5 years ago	Improve proposal reviews Improve proposal reviews Display talk format or proposal kind on review tables and in CSV. Add suggested status to CSV output, for auto-accept and auto-reject. Add endpoint to download CSV of proposals for section.
James Polley	227df66dba0b	6 years ago	Allow non-managers to submit review feedback
James Polley	ecd4bc97bc0f	7 years ago	Expand bulk_accept to generic bulk_update Expand bulk_accept to generic bulk_update Allows for bulk rejection/undecided/standby in addition to bulk accept.
James Polley	5114076afa2f	7 years ago	Make review changes atomic Make review changes atomic 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.
James Polley	7fe5a09bfb9b	7 years ago	Return an integer for the slice index. Return an integer for the slice index. 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
Sachi King	89e74a6f111e	7 years ago	Order by ID rather than at last update time Order by ID rather than at last update time 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.
Sachi King	d95d66dac8b2	7 years ago	Taking one out of PyCon's (US) book Taking one out of PyCon's (US) book We're lock-step with symposion, and upstream is dead. Vendor it.