User stories

As a ucsb student
I can apply to use the Gauchoride service
So that if I have mobility issues, I can still get to class
As an admin
I can approve or deny requests to use the service, and track pending requests
So that I can manage demand for the service, and prioritize students with the greatest need

Discussion

The program will be scaling up slowly, and it is unknown how many students may need/want to take advantage of the service.

Accordingly, it will be helpful to have a waitlist of users that are applying to be riders.

Acceptance Criteria

Acceptance Criteria: Rider Perspective

[ ] Any user that logs in with an @ucsb.edu email (ROLE_MEMBER in the code) should be able to see a menu option: Apply to be a Rider on the main menu bar.
[ ] When clicked, Apply to be a Rider takes the user to a form page at /apply/rider
[ ] The page /apply/rider will show a list of applications that the rider has made previously, with buttons to show, edit, and cancel an application. The columns will show the id of the application, the date created, the date last updated, and the status (see below)
[ ] The user may click "show" to see the details of any application on the page; the url will be /apply/rider/show/:id This takes them to a page where they can see the details of their application, but cannot edit them.
[ ] The user may click "edit" only on an application that is "pending"; in that case, they will be taken to a page where they can edit their application. The url will be /apply/rider/edit/:id
[ ] The user may click "cancel" only on an application that is "pending"; in that case, they will shown an "are you sure you want to cancel" this application with options "Yes, Cancel" and "No, Keep my Application Active". If they click Yes, the application will be put into "cancelled" status. This option keeps them on the /apply/rider page.
[ ] The form at /apply/rider will contain the following fields listed below

Fields on RiderApplicationForm

id (only if the rider has already applied; this should be labelled as applicant id on the form, but is just id internally)
status this will be pre-populated with the status of the application: (pending for newly created applications) and will not be editable. See status values below.
email this will be pre-populated from the current user and will not be editable, but will appear
perm_number This field will be editable and will accept the perm number. Perm numbers are 7 characters, and are now alphanumeric (not just numeric).
date applied this will be pre-populated with the date the application was first created, and is not editable
date updated this will be pre-populated with the date the application was last updated.
date cancelled this will be pre-populated with the date the application was cancelled (if and only if it was cancelled)
description This will be an editable text field that should be, initially, the full width of the container and at least 6 lines of text high, and should be expandable. It will be labelled with "Please describe the mobility limitations that cause you to need to use the Gauchoride service."
notes This will be a text field that is not editable by the applicant, but will contain information entered by the admin that acts on the application. This field is for communicating information back to the applicant about the status of their application.

Statuses

pending (no action yet)
accepted (user is now an active rider)
declined (user was not approved to be a rider)
expired (user was previously a rider but must reapply to be a rider again)
or cancelled (cancelled by the user).

Acceptance Criteria: Admin Perspective

[ ] On the Admin menu there is an option Rider Applications that takes the admin user to a page /admin/applications/riders
[ ] On that page the admin can see separate tables: one labelled Pending Rider Applications with all currently pending rider applications, and a second labelled All Rider Applications which contains all rider applications.
[ ] Both tables have Review buttons that take the admin to a page /admin/applications/riders/review/:id where the admin can see all of the fields in the application, but can edit the notes field.
[ ] For pending applications, the admin has buttons to "Approve", "Deny", "Save". All three save any edits to the response field. In addition, "Accept" or "Decline" will change the status of the application to "Accepted" or "Declined". There is also a "Return without Saving" button that returns to the /admin/applications/riders without saving any changes to the form.
[ ] For applications in the status "accepted", there is a button on the /admin/applications/riders/review/:id page called "Set Status to Expired", and one called "Return without Saving". In this case the notes field is editable. The "Set Status to Expired" button will update the status to expired and save the changes. The "Return without Saving" returns to the /admin/applications/riders discarding any changes to the form.
[ ] For applications in the status "declined" or "cancelled" there are no editable fields on the /admin/applications/riders/review/:id page and just one button "Return" that returns to the /admin/applications/riders page.

Implementation Todos

First issue: Create database record and fixtures

[x] There is an @Entity called RiderApplication with fields: Long id, String status, Long userId, String perm_number, Date created_date, Date updated_date, Date cancelled_date, String description , String notes
[x] There is a @Repository called RiderApplicationRepository
[x] There is a fixtures files riderApplicationFixtures.js

Second issue: RiderApplicationController

These endpoints are for Members (users with UCSB email addresses) only:

[x] There is an API endpoint POST /api/riderApplication/new for creating a new rider application with the current user as the requester, provided the current user has ROLE_MEMBER (i.e. has a ucsb email address).
[x] There is an API endpoint GET /api/rider that gets all rider requests owned by the current user
[x] There is an API endpoint GET /api/riderApplication?id=123 that gets a rider request but only if owned by the current user.
[x] There is an API endpoint PUT /api/riderApplication that takes a request body with the json for a rider application for editing an existing rider application but only if it is owned by the current user and the application is in the correct status (otherwise errors should be returned)
[x] There is an API endpoint PUT /api/riderApplication/cancel?id=123 for cancelling an existing rider application but only if it is owned by the current user and the application is in the correct status (otherwise errors should be returned)

These endpoints are for Admins only:

[x] There is an API endpoint GET /api/rider/admin/all that gets all rider requests (paged; see below)
[x] There is an API endpoint GET /api/rider/admin/pending that gets all pending rider requests (paged; see below)
[x] There is an API endpoint GET /api/rider/admin?id=123 that will get a specific rider request
[x] There is an API endpoint PUT /api/rider/admin that will allow an admin to update a rider request, but only the status and/or the notes field.

Third issue: RiderApplicationForm

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

Fourth issue: RiderApplicationTable

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

Fifth issue: Rider Pages

[ ] There are is a page component at the /apply/rider url that meets all of the acceptance criteria.
[ ] There is a page component for the /apply/rider/edit/:id url that meets all of the acceptance criteria
[ ] All other acceptance criteria from the rider perspective listed above are met

Sixth issue: Admin Pages

[ ] There are is a page component at the /admin/applications/riders url that meets all of the acceptance criteria.
[ ] There is a page component for the /admin/applications/riders/review?id=123 url that meets all of the acceptance criteria
[ ] All other acceptance criteria from the admin perspective listed above are met

ucsb-cs156-m23 / proj-gauchoride-m23-9am-1

EPIC: Students can apply to use the Gauchoride service, and admins can manage applications #20