feat(coworking)!: room reservations enhancements and group room reservations

[ajaygandecha]

This PR makes major changes to the room reservation feature in the XL site that adds group reservations, helps instructors with reserving rooms, helps administrators manage operating hours, and updates the UI to conform to Material standards. The application is also upgraded to Angular v20 and begins an incremental adoption of TailwindCSS.

Features

The following features have been added in this update:

• Brand new UI: The room reservations UI has been updated to conform to Material 3 standards, the final feature in the XL application to be redesigned for M3. The UI is now more responsive for mobile usage. Selecting time ranges is now more intuitive - instead of having to select each 30min increment, simply click on the start and end of the interval and all slots between the start and end are selected.
• Group room reservations: When reserving rooms, users now must supply other students to reserve the room with. For all rooms, the minimum number of required students per reservation has been set to ceil(capacity / 2) as recommended in the final project idea for COMP423. The maximum number of students per reservation is based on the capacity of the room. Any group member is able to cancel the reservation.
• Instructor Permissions: Instructors now do not have a limit for reserving rooms, which is helpful in cases like the check-off activities in COMP211. To prevent abuse, this is limited to instructors only (not GTA/UTAs).
• Office Hour Room Conflicts: Rooms that have scheduled office hours events are no longer reservable and show up as reserved. This ensures that the administrator does not have to set custom operating hours around these times or use another workaround.
• Base Operating Hours Editor: A very minimal operating hours editor has been added for the administrator so that they can see upcoming operating hours, create new ones, or delete existing ones. This management is accessible from the admin tab.

General Project Changes

• Angular v20: This PR upgrades the application to use Angular v20 and Angular Material v20. The motivation for this is to add newer UI components (like the time picker) and also so that CSS variables are accessible for Material styling.
• Incremental TailwindCSS Adoption: TailwindCSS has been introduced for the new features and will make the maintainability of the website and CSS far easier than it has been before. There will be a future PR to migrate most of the UI to use Tailwind soon.

Future Work

• We can add a custom configuration for mobile devices instead of using the grid.
• Operating hours functionality should be extended.
• Future work can be done on the grid, such as the ability to click on a blue reservation and have options to cancel it.

[KrisJordan]

This is looking awesome!

Couple of quick questions:

1. After resetting demo, it should be possible to create a reservation? I'm seeing an error on my end that I'm guessing is because my timezone is +6. I get a 500 validation error in pydantic in the backend (Value error, end must be greater than start). Looking at the JSON Payload, start is 2025-09-13T06:30:00.000Z and end is 2025-09-13T07:30:00.000Z, so I'm perplexed.

2. When you say "Rooms that have scheduled office hours events are no longer reservable and show up as reserved." does that mean that if an instructor/TA makes an office hours event that has a room in the XL associated with it, they're automatically booking out that room? Are they prevented from doing so if there's already a conflicting reservation (either another course's office hours or someone made a standard reservation)? This overrides the need to add users to a reservation? (I know I could look at this in a code review, but for time purposes) is an actual reservation for the room also made or is the logic for availability more complex in looking for the existence of either a reservation or an office hours event?

3. Is the system still in place for looking at the policy to see the blocked off hours for non-reservable rooms? This remains important because there are a number of courses which do not use an office hours system (such as Saba's and Sridhar's) that we need to block off times for the semester on.

4. I think I'm in favor of floor(capacity / 2) as a starting point and seeing how it goes as we transition to this. I think we need a slightly more obvious UX for hitting this number. Maybe the text of the Reserve button updates (1 more person needed to reserve) or perhaps a tooltip or red label next to the reserve button or something. The label of the field's text is so small and easy to miss (esp coming from a world where this wasn't part of the process).

[ajaygandecha]

Thank you @KrisJordan!

1. Yes, it should be possible to reserve after running reset demo.

2. Currently, if an office hours event is happening during a certain time slot, users will no longer be able to make a reservation during the time slot - an automatic reservation is not made for the instructor for that time (though that is possible if preferred). Instructors have priority, so creating an office hours event for a location does not fail if an existing reservation exists. There is currently missing logic to automatically cancel existing reservations, but this can be added. My main concern here was with notification, I feel that some sort of email notification would be appropriate here (but we might be able to add this next). Also, creating an office hours event for a room that already has office hours does not fail since many rooms are shared between instructors.

3. No, but I will add this back now! Another good stretch goal is probably to add a UI for managing the policy.

4. Good call, will add!

[ajaygandecha]

@KrisJordan, I modified the current implementation to add a new policy for instructors (separate from the user policy). The policy.py file has been modified accordingly! The implementation can also be extended for future policies in the future, including ambassadors, etc.

Also, want to ask a bit more clarity (to refresh my memory) on what we decided regarding office hours. I have been thinking a bit more about the refactor to a state where singular office hours events (not recurring) creates a reservation for that time in the room. I feel like there may be edge cases, particularly when sharing rooms, that might increase complexity for both a backend refactor and also on the instructor side. Given the current use case right now, I am wondering if the current implementation is fine (along with bringing back relying on the OH_POLICY object for manual room closures).

The recent modifications change the functionality so that instructors can reserve more weeks in advance and have no hours limits, which should suffice for COMP211's purposes. I am assuming the onus being on instructors not to abuse the system will be better / easier to enforce than all staff (including UTAs)?

If this sounds good, the current implementation here may be "good enough" for the immediate concerns (for the small edge case of instructor room reservations) and include a significant UI improvement for all users on the site, which also unblocks the Tailwind migration! As we were brainstorming, the reservations for OH could be shifted to a 423/523 project!