USER STORY: Choice of Table

[DiarmuidHenry]

As a user, I can choose the table I would like to sit at so that I can better control my dining surroundings.

Acceptance Criteria

• [x] The check_availability function returns a list of tables that the guest can choose from.
• [x] Booking an oversized table is avoided where possible, e.g. a group of 3 will not be given the option to book a table for 8, if a table for 4 or 6 is available.
• [x] A diagram of the restaurant and its tables is shown for reference.
• [ ] Larger groups can select multiple tables to spread their party between.
• [ ] The diagram of the restaurant tables is an interactive map that the users can click on. By the tables' colouring, they user can easily see which tables are available. Clicking on said table, will assign that table to the user's booking.

[DiarmuidHenry]

The interactive map was a larger task than anticipated, so this acceptance criteria will remain unfulfilled.

[DiarmuidHenry]

Spreading a single group over multiple tables meant a reworking of the model and the logic that I felt was not worth the time investment. A work around is that I have added a sort of error validation, so that larger groups should use the Contact page if they have a large party. The page they are redirected to has a pre-populated First Name, Last Name, Email and Subject field, in order to speed up their enquiry, as well as to give a standard outline to the requests that the restaurant's email address receives.