Overlapping Rotations

As documented in commit 5e24761, rotations can overlap by a bit. The UI can only handle overlaps for some values of "a bit":

• Students can only see the list of projects for the latest rotation, but they make their project choices by using that list. Therefore, the latest rotation must be the same as the rotation that project choices are being made for, for the entire duration of the choice-making period (that is, until student_choice).
• The "finalise projects" link in the header uses the latest rotation to decide which rotation to link to, so the latest rotation must be the same as the rotation that needs finalising, until the rotation is finalised.
• Various other parts of the UI (e.g. creating projects) currently have no way to select a rotation either.

These issues are all fundamentally fixable, by sending the rotation on which to operate in the request and/or exposing some UI (a dropdown) to select the correct rotation, but it usually only makes sense to perform any given action (e.g. creating projects, finalising assignments, uploading reports) on one rotation at any given time, so it's easier to enforce that rotations only overlap by "a bit" rather than adding heaps of new UI and making the application ugly and hard to use, or adding new logic (and more network requests) to work out which rotation the user means to act upon.

A slightly corrected version of the commit message referenced earlier (clarifying that event D represents both the student_choice deadline passing and the Graduate Office finalising project assignments) is as follows:

To see why it's safe for rotations to overlap (and to explain how much they can overlap without issues), here's an annotated diagram of three rotations, with time on the x-axis:

                                   A: start of the rotation
                                   B: supervisor_submit
                                   C: student_invite
A1  B1 C1     D1         E1  F1    D: student_choice and finalisation
┌───┬──┬──────┬──────────┬───┐     E: student_complete
│   │  │      │          │   │     F: marking_complete
└───┴──┴──────┴──────────┴───┘
                   It's important that these events
              ├──┤ (D1 and A2) occur in this order! ──────────┐
                                                              ▼
                 A2  B2 C2     D2         E2  F2    ...because students
                 ┌───┬──┬──────┬──────────┬───┐     can only choose from
                 │   │  │      │          │   │     the latest rotation.
                 └───┴──┴──────┴──────────┴───┘               ▲
                                         Likewise with        │
                               ├───────┤ D2 and A3. ──────────┘

                                       A3  B3 C3     D3         E3  F3
                                       ┌───┬──┬──────┬──────────┬───┐
        However, all other events      │   │  │      │          │   │
        can occur in any order.        └───┴──┴──────┴──────────┴───┘

As the diagram says, it's important that students make their project choices before the next rotation is created. This is the case because students are locked into viewing only the latest rotation in the "All Projects" page (unlike staff, who can view any rotation in the system), so if a new rotation is created before a student has chosen their project, then they will not be able to access the list of projects from that rotation any more.

In addition, the finalisation screen acts upon the most recent rotation, so a new rotation can't be created before the existing rotation is finalised (plus projects are always created in the latest rotation, and probably other things).

However, after finalisation, nothing needs to refer to the first rotation any more; finalised rotations are read-only, so projects can't be created in the original rotation, and that's essentially the only thing that refers to "the latest" rotation in an important way (it's used as the default rotation in some places, and it determines which header links are shown, but the "view student choices" page -- which is the only other dynamic header link -- is meaningless for finalised rotations anyway). Therefore, as far as I can tell, it's safe to create a new rotation once the existing rotation has been finalised.