Commit graph

11 commits

Author SHA1 Message Date
Joel Addison
252697b842 Update to Django 2.2
Upgrade site and modules to Django 2.2. Remove and replace obsolete
functionality with current equivalents. Update requirements to latest
versions where possible. Remove unused dependencies.
2020-11-22 23:58:14 +10:00
Joel Addison
ac57053ecf Ignore withdrawn proposals for random choice 2020-11-19 12:20:49 +00:00
Joel Addison
37a02c1704 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.
2019-10-14 21:26:49 +10:00
Joel Addison
94f8837288 Allow admin to manage own proposals
Do not block admins from changing votes, result or messaging
on their own proposals.
2019-10-02 23:27:51 +10:00
Joel Addison
87ecc83314 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.
2019-08-29 22:05:00 +10:00
James Polley
227df66dba Allow non-managers to submit review feedback 2018-06-27 19:13:00 +10:00
James Polley
ecd4bc97bc Expand bulk_accept to generic bulk_update
Allows for bulk rejection/undecided/standby in addition to bulk accept.
2017-09-17 13:15:56 +10:00
James Polley
5114076afa 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.
2017-08-09 12:27:41 +10:00
James Polley
7fe5a09bfb 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
2017-08-08 23:00:36 +00:00
Sachi King
89e74a6f11 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.
2017-07-14 21:19:28 +10:00
Sachi King
d95d66dac8 Taking one out of PyCon's (US) book
We're lock-step with symposion, and upstream is dead.
Vendor it.
2017-05-27 20:11:39 +10:00
Renamed from symposion/reviews/views.py (Browse further)