This makes bookings impossible

Some rooms may only be booked by certain rooms. An allowlist option could be added to rooms that only enable certain groups to create bookings, or even see the room at all.

• Delete existing backend folder in monorepo
• Install typescript
• Install eslint
• Set up dev environment with nodemon + docker

implement webhook integration

Currently the approvers don't see other people's requests nor do they see their own requests that are sent to themselves.

I'm assuming that "approving" isn't setup properly.

Some rooms might not need approval to be booked, i.e., are auto-approved. These rooms thus do not need approval, or may only have a quota (see #148).

Since the Hacklab is getting an iPad instead, we need a route that emulates the layout of the Joan 6

• Create frontend page
• Set up WiFi on iPad

When receiving errors from the backend, show them in frontend.

There seems to be a consensus that adding a Professor to a group isn't the way to go. What should happen is that an admin needs to add "approvers" which students can add (checkboxes) to their groups.

Wrt T-Card access granters, this should be a list of people too. Right now only Andrew Wang does it, but in future this could change.

Allow a user to see the bookings for a room in their calendar by adding an ical link for each room, which is generated from the booking data.

By using ical instead of Google Calendar API, we are able to make this integration cross-platform

A theoretical threat actor may create pending bookings, blocking future bookings for any other user. A proposed solution is:

• Allow users to book overlapping pending bookings
• When an approver looks over it, only one booking can be accepted, the other gets automatically denied
• Frontend: a different colour is shown for pending bookings but users are allowed to book

We need documentation on

• how to maintain the web app,
• general design decisions
• database relations
• how to deploy
• backend API routes
• user flow chart
• tech stack
• purpose
• scope

It has to

• be deployed on GitHub wiki
• have a short, condensed version as the README.md
• be generally readable to audiences that are not familiar with tech

2 requests for the same date/time should not be permitted -- putting a hold in the calendar might be a good way to resolve this.

To prevent excessive bookings, allow the option for rooms to limit the number of hours per group or student. Some options for how to ratelimit could be provided to the administrators, including:

• ratelimit based on the number of hours the booking author has booked in the past
• ratelimit based on the number of hours the group creating the booking has booked in the past
• ratelimit based on the minimum value of the both above

Admins should not necessarily be exposed to students to be chosen for booking. Split this list by adding an approvers list for each room that is independent of the admin role

• implement dark mode

Some rooms do not require T-card access. Make a room-specific config that makes the requests for those rooms not require t-card approval.

Add a UI that lets users see the groups they have been invited to and accept/deny the invitation

Currently, emails are sent in plain text with no calls to action. This makes it annoying for users to type the URL manually.

Ideally, approvers should be able to

1. Click "yes" / "no" on the email itself
2. Log in using SSO
3. Provide a reason after authentication
4. Done!

If there is a request, an email notification should come in.

wiki linked here

title

Make a room-specific setting that allows users to only book a given room during specific times of the day.

Example use case:
Book a meeting with TAs during office hours