Create a page for departments to view their allocations

[fritzj2]

Semester Team Info

• Current functionality does work; this branch also contains fixes for a test that is brittle. The changes made are not feasible in the current implementation, since they are more of a workaround for the failing test than an actual fix.

Issue Description

Fixes issue #607

• Create a page for departments to view their current allocations. This should include both contracts and given allocations for the current term

Additions

• allocationTable html, css, and js, all handle the UI.
  allocationTable.js is needed because there are 6 Bootstrap DataTables on the page.

Changes

• main_routes.py includes a section that navigates to the page
• The allocationManager.py file includes 1 new function, getContractedAllocations(). This function gathers the number of hours for the break terms.
• Lots of new objects in demo_data.py, which include more LSFs, formHistory, students, and terms.

Rationale

• This logic depends on having access to a term that aligns with the current year. main_routes.py contains a function that retrieves the current date and uses its year-end to determine the current term.

  • This term check flips on July 1st, as it is the day when the terms change for the labor office.
  • This check exists to get around there being no sense of a currentTerm in the system

• The page will not physically load if there is no term for the current year.

• The page also fails to load if there is no Allocation object for the current term.

• Retrieving formHistory objects has a lot of nuance to it.

• Contracts have many different ways that they can be written for only one term, including:

  • Changing term to Fall 2026 / Spring 2026
  • Changing the start / end date to the end of a semester
  • The kind of position (Primary vs Secondary)
  • The type of position (Weekly Hours vs Contract Hours)

• The Reasoning behind the complex query is that there are many different ways in which a Labor Status form differentiates term contracts, yearly contracts, and break contracts.

• The Supervisors can pick whichever way they choose to build the Labor Status Form, and the function needs to be prepared to deal with all of the cases present.

• Breaks are hard to justify their place in the table. As nice as they are, it is hard to see the information that someone may want at a given time

• The current implementation has all of the break allocations for a selected term. The problem is the summer term.

• Summer term starts after fall term.

  • The problem is that after July 1st, the next year's summer information will be displayed.
  • This is helpful as most of the longer summer term positions are finalized
    • As for the contracts that start after July 1st (think RAs who start ~August 1st), they can't be viewed since the term has rolled over.

Testing

• Reset the database to test data (or the allocation grab function breaks the page)
• Navigate into the allocations page (home page -> Department Portal -> Computer Science -> Allocation Card -> View Allocations)
  • Other departments require an allocation model to be added for the page to load.
    • INSERT INTO allocation (id, department_id, isFinal, termCode_id, justification, primary_10, primary_12, primary_15, primary_20, secondary_5, secondary_10, breakHours) VALUES (222, 2, 1, 202600, "ETAD allocation", 1,1,1,1,1,1,111); will give you an allocation for the ETAD department, which will load the page afterward.
• View the tables nested in the accordions, ensure that it is pulling formHistory and allocations
• Ensure that users not part of a specified department cannot access another department's page.
  • The quickest way to test this is by changing users in secret_config.yaml
• Mess with the data, ensure that the page loads with no contracts.
• Check what happens with bad LSFs added to the data, such as with dates, terms, jobTypes, and contractHours.
• Check the test suite and ensure all tests are passing
• Check that the test_allocationManager.py test is passing, most importantly.

[BhushanSah]

Can we clean up this date filtering?

This currently compares extracted month values to string values like "07" and "08". It may be safer to compare against actual dates or the selected term’s termStart / termEnd instead of only checking months. Month-only logic can get confusing for contracts that cross years, cover the full academic year, or overlap summer.

[fritzj2]

As interesting a concept as it sounds, the impact on code performance here is almost negligible. In the end, the check for the year-long positions checks the end-of-year dates anyway. e.g. (lsf.startDate >= AY.startDate) & lsf.startDate <= AY.endDate).

• In the end, it requires a comparison that changes the implementation to check the same thing. It still checks if it pushes into the end of the year regardless.
• To change this implementation to be more strict, it requires us to always pass in a fall and spring term into the code, which we may not always need. This implementation is also the longest of all the options and the hardest to read.
• The edge case that this fixes, however, is a termDate change. Where the end of a Fall term ends in January, instead of December.

The end code requires many comparisons, which makes the already hard-to-read code even harder to read and debug, for very little benefit.

[BhushanSah]

I do not see routes for /allocations/download or /allocations/request in this PR.

Can we either add those routes or remove/disable these buttons for now? Otherwise users can click them and hit a 404.

[fritzj2]

This is not in the scope of this issue; check out #668 for the branch that adds the route for the allocation request.

[BhushanSah]

This makes the Tracy test less strict.

The old test checked the exact returned names and CPOs. The new version only checks that each expected value appears somewhere, so it would still pass if extra students are returned or if names and CPOs no longer match the same records.

Can we keep this test stricter, or update it in a way that still verifies the full expected result?

[fritzj2]

For the Semester Team

This change was originally meant to fix an extremely brittle test, which, thanks to my demo_data.py changes, now fails
There are a few ways to go around this, such as adding atomic students to the test rather than relying on existing database students, or checking a small subset of the data instead of the entire database.

This is the function that adds students to Tracy in demo_data.py; this could be used to make atomic students.
# Add students to Tracy db
with app.app_context():
for student in (tracyStudents + bothStudents):
db.session.add(STUDATA(**student))
db.session.commit()

# Add the Student records
students = []
for student in (localStudents + bothStudents):
# Set up lsf db data
del student["PIDM"]
student['ID'] = student['ID'].strip()
student['legal_name'] = student['FIRST_NAME'].strip()
del student['FIRST_NAME']

students.append(student)
Student.insert_many(students).on_conflict_replace().execute()