EPIC: Driver Availability

User stories

As a driver
I can enter my availability to work shifts
so that admins can set up a shift table that works with driver availability
As an admin
I can view all driver's availability
so that I can set up a shift table that works with driver availability

Discussion

Previously, there was some confusion about whether drivers should be able to directly do CRUD operations on their own shifts. Since then, we have determined, by talking with the folks running the service, that instead, we want to separate out two different functions:

Driver availability, which drivers should be able to enter directly.
Driver shifts, which only admins should be able to touch.

Ability of the admin to edit or delete driver availability is up to further discussion

In this epic, we will add a separate CRUD operations for driver availability, which drivers will be able to directly edit. In addition, we want to clarify that only Admins can edit the driver shift table.

Acceptance Criteria: Driver Perspective

[ ] Any driver (ROLE_DRIVER) should be able to see a menu option Availability under Shifts on the navbar.
[ ] When clicked it takes the user to a table that shows the availability that the driver has previously submitted.
[ ] The user can click a button at the top of the table that goes to /availability/create where they can submit their availability for a specific day of the week.
[ ] The user can click "edit" in order to edit a previously submitted availability.

Fields on AvailabilityForm

Some way to identify who submitted the availability. This can be their driver id, or prepopulated name/email from the user.
Day.
Start is when the driver starts being available.
End is when the driver is no longer available.
Notes if the driver has any additional comments regarding their availability.

Acceptance Criteria: Admin Perspective

[ ] Under the admin option of the navbar there is an option Driver Availability where they can see all drivers' availability.
[ ] If the Availability uses the driver id, the admin should be able to click the driver id to see more details about the driver.

Implementation Todos

1st issue: Database record and fixtures

[x] There is an @Entity called DriverAvailability with fields: Long id, (type depends) driverId, String day, String startTime, String endTime, String notes.
[x] There is a @Repository called DriverAvailabilityRepository.
[x] There is a fixtures file driverAvailabilityFixtures.js.

2nd issue: DriverAvailabilityController

[ ] There is an API endpoint POST /api/driverAvailability/new for creating a new driver availability submission with the current user as the requester, given that the user has ROLE_DRIVER.
[ ] There is an endpoint GET /api/driverAvailability that gets all availability submissions for the current user.
[ ] GET /api/driverAvailability?id=123 that gets an availability submission if owned by the current user.
[ ] PUT /api/driverAvailability that edits an availability if owned by current user.
[ ] DELETE /api/driverAvailability that deletes an availability if owned by current user.

For admins:

[x] GET /api/driverAvailability/admin/all that gets all driver availabilities.
[x] GET /api/driverAvailability/admin?id=123 that gets a specific driver availability.

3rd issue: DriverAvailabilityForm

[ ] There is a react component DriverAvailabilityForm that is suitable for use on the pages described in the acceptance criteria
[ ] There are storybook entries

4th issue: DriverAvailabilityTable

[ ] There is a react component DriverAvailabilityTable that is suitable for use on the pages described in the acceptance criteria
[ ] There are storybook entries

5th issue: Driver pages

[ ] There are page components that meet all of the acceptance criteria from the driver perspective (index, create, edit)
[ ] Storybook entries

6th issue: Admin Pages

[ ] There are page components that meet all of the acceptance criteria from the admin perspective (index)
[ ] Storybook entries

ucsb-cs156-w24 / proj-gauchoride-w24-7pm-4