Periodic Tables

Frontend: https://restaurant-frontend-20220224.herokuapp.com/dashboard Backend: https://restaurant-backend-20220224.herokuapp.com/

This is an application designed for use by restaurant managers to schedule reservations and seat them accordingly. The client is built with React, and the backend is built with Express and connects to a database hosted on ElephantSQL.

Features include:

• Making new reservations
• Editting existing reservations
• Searching tables by phone number
• Making new tables
• Assigning reservations to tables
• Finishing tables

Installation

1. Fork and clone this repository.
2. Run cp ./back-end/.env.sample ./back-end/.env.
3. Update the ./back-end/.env file with the connection URL's to your ElephantSQL database instance.
4. Run cp ./front-end/.env.sample ./front-end/.env.
5. You should not need to make changes to the ./front-end/.env file unless you want to connect to a backend at a location other than http://localhost:5000.
6. Run npm install to install project dependencies.
7. Run npm run start:dev to start your server in development mode.

API

1. The /reservations/new page will

   • have the following required and not-nullable fields:
     • First name: <input name="first_name" />
     • Last name: <input name="last_name" />
     • Mobile number: <input name="mobile_number" />
     • Date of reservation: <input name="reservation_date" />
     • Time of reservation: <input name="reservation_time" />
     • Number of people in the party, which must be at least 1 person. <input name="people" />
   • display a Submit button that, when clicked, saves the new reservation, then displays the /dashboard page for the date of the new reservation
   • display a Cancel button that, when clicked, returns the user to the previous page
   • display any error messages returned from the API

2. The /dashboard page will

   • list all reservations for one date only. (E.g. if the URL is /dashboard?date=2035-12-30 then send a GET to /reservations?date=2035-12-30 to list the reservations for that date). The date is defaulted to today, and the reservations are sorted by time.
   • display next, previous, and today buttons that allow the user to see reservations on other dates
   • display any error messages returned from the API

3. The /reservations API will have the same validations as above and will return 400, along with an informative error message, when a validation error happens.

   • seed the reservations table with the data contained in ./back-end/src/db/seeds/00-reservations.json

4. The /reservations/new page will display an error message with className="alert alert-danger" if any of the following constraints are violated:

   • The reservation date is a Tuesday as the restaurant is closed on Tuesdays.
   • The reservation date is in the past. Only future reservations are allowed.

5. The /reservations API will have the same validations as above and will return 400, along with an informative error message, when a validation error happens.

6. The /reservations/new page will display an error message with className="alert alert-danger", if any of the following additional constraints are violated:

   • The reservation time is before 10:30 AM.
   • The reservation time is after 9:30 PM, because the restaurant closes at 10:30 PM and the customer needs to have time to enjoy their meal.
   • The reservation date and time combination is in the past. Only future reservations are allowed. E.g., if it is noon, only allow reservations starting after noon today.

7. The /reservations API will have the same validations as above and will return 400, along with an informative error message, when a validation error happens.

8. The /tables/new page will

   • have the following required and not-nullable fields:
     • Table name: <input name="table_name" />, which must be at least 2 characters long.
     • Capacity: <input name="capacity" />, this is the number of people that can be seated at the table, which must be at least 1 person.
   • display a Submit button that, when clicked, saves the new table then displays the /dashboard page
   • display a Cancel button that, when clicked, returns the user to the previous page

9. The /dashboard page will:

   • display a list of all reservations in one area.
   • each reservation in the list will:
     • Display a "Seat" button on each reservation.
   • display a list of all tables, sorted by table_name, in another area of the dashboard
     • Each table will display "Free" or "Occupied" depending on whether a reservation is seated at the table.

10. The /reservations/:reservation_id/seat page will

    • have the following required and not-nullable fields:
      • Table number: <select name="table_id" />. The text of each option must be {table.table_name} - {table.capacity} so the tests can find the options.
    • do not seat a reservation with more people than the capacity of the table
    • display a Submit button that, when clicked, assigns the table to the reservation then displays the /dashboard page
    • PUT to /tables/:table_id/seat/ in order to save the table assignment. The body of the request must be { data: { reservation_id: x } } where x is the reservation_id of the reservation being seated. The tests do not check the body returned by this request.
    • display a Cancel button that, when clicked, returns the user to the previous page

11. The /tables API will have the same validations as above and will return 400, along with an informative error message, when a validation error happens.

12. The /dashboard page will

    • Display a "Finish" button on each occupied table.
    • Clicking the "Finish" button will display the following confirmation: "Is this table ready to seat new guests? This cannot be undone." If the user selects "Ok" the system will: - Send a DELETE request to /tables/:table_id/seat in order to remove the table assignment. The tests do not check the body returned by this request.
    • The server should return 400 if the table is not occupied.
    • Refresh the list of tables to show that the table is now available.
    • Clicking the "Cancel" makes no changes.

13. The /dashboard page will

    • display the status of the reservation. The default status is "booked"
    • display the Seat button only when the reservation status is "booked".
    • clicking the Seat button changes the status to "seated" and hides the Seat button.
    • clicking the Finish button associated with the table changes the reservation status to "finished" and removes the reservation from the dashboard.
    • to set the status, PUT to /reservations/:reservation_id/status with a body of {data: { status: "<new-status>" } } where <new-status> is one of booked, seated, or finished. Please note that this is only tested in the back-end for now.

14. The /search page will

    • Display a search box <input name="mobile_number" /> that displays the placeholder text: "Enter a customer's phone number"
    • Display a "Find" button next to the search box.
    • Clicking on the "Find" button will submit a request to the server (e.g. GET /reservations?mobile_number=800-555-1212).
      • then the system will look for the reservation(s) in the database and display all matched records on the /search page using the same reservations list component as the /dashboard page.
      • the search page will display all reservations matching the phone number, regardless of status.
    • display No reservations found if there are no records found after clicking the Find button.

15. The /dashboard and the /search page will

    • Display an "Edit" button next to each reservation
      • Clicking the "Edit" button will navigate the user to the /reservations/:reservation_id/edit page
    • Display a "Cancel" button next to each reservation.
    • Clicking the "Cancel" button will display the following confirmation: "Do you want to cancel this reservation? This cannot be undone."
      • Clicking "Ok" on the confirmation dialog, sets the reservation status to cancelled, and the results on the page are refreshed.
        • set the status of the reservation to cancelled using a PUT to /reservations/:reservation_id/status with a body of {data: { status: "cancelled" } }.
      • Clicking "Cancel" on the confirmation dialog makes no changes.

16. The /reservations/:reservation_id/edit page will display the reservation form with the existing reservation data filled in

    • Only reservations with a status of "booked" can be edited.
    • Clicking the "Submit" button will save the reservation, then displays the previous page.
    • Clicking "Cancel" makes no changes, then display the previous page.