**Note**: This section is outdated. Please, refer to the [Wiki page](./Home.md) for the latest information.

Here you can find the individual project analysis made to come up with the dimensions of the project.

# Client prespective: By alexeses
To have a functional version and start working optimally, I was thinking of the following:

1. The user authentication system based on email/password will not exist, this will be replaced by reading a **QR CODE** that the user will have at the table. When opening the APP, the user will be asked to turn on the camera or **manually enter** the **code** if the QR or mobile camera fails. *See section 1.1
2. Once the QR code is scanned or the code is manually entered, the user will access the screen to select all the dishes they want to order (one or several dishes per category...). *See section 2.1
3. After selecting the dishes and confirming the selection, the user will move to the screen to confirm the order and pay for it to be sent to the kitchen. *See section 3.1
4. The user will have full access to review their orders in progress and/or completed. (_HOW DO WE STORE THE ORDERS IF WE DO NOT HAVE A UNIQUE ID PER CLIENT?_ [Chat GPT moment: How to get IMEI or ID mobile from app](https://stackoverflow.com/questions/2785485/is-there-a-unique-android-device-id))

<details><summary>1.1</summary>
In my opinion, this is the smartest option since we save the authentication system and the listing of free/occupied tables.

If the user has a camera-enabled terminal and/or functional, from the application they can scan the QR code that must be unique to the table. If they do not have a camera or have problems, the user can manually enter the code and follow the ordering process.

The QR code should not be anything complex, since we are talking about unique codes for each local/table, for example: SUMO-00-001 // (restaurant initials)-(restaurant id)-(table).

Based on this generated code, we can make a direct communication with the backend and send all the necessary information to process the order.
</details> 

<details><summary>2.1</summary>
The product screen will be interactive with the possibility of selecting one or several products with a product search engine and categories/sections for the different dishes.

This step may seem trivial, but it is VERY IMPORTANT to create dishes with as much information as possible:
- Name
- Image associated with the dish
- Description
- Section: Starter, Side dish, Main dish, Dessert, Drink...
- Allergies
- And much more: Among us all, we must provide data to categorize the dishes in a very simple way.
</details> 

<details><summary>3.1</summary>
For now, as we do not have a payment system, we will simulate the payment and the order will go to the kitchen.
</details> 

Regarding the databases:
Instead of having unique users, we will have unique device IDs, which will be automatically registered in the database when the QR code is scanned.

Each unique customer identifier will store sessions (with a timestamp of the scan time, for example), and based on this data, we will add attributes to the datababase. What do you think? The only problem is figuring out if we can obtain the unique mobile device identifier.

Please, I am open to modifications and feedback from your side, the clearer we all have it, the better. The task is not finished yet, we must create a design base for the interfaces.


# Staff perspective: By mariaduva
Hi everyone!

Here are my ideas for the staff's experience. To make things simpler and organized, I've divided them into modules so we can discuss each one separately and in more detail.

MODULE 1: STAFF AUTHENTICATION
The staff authentication window will be a secure login screen that requires staff to enter their id and password. The system will authenticate the user's credentials and provide access to the administration area if they are correct. If a new staff member needs to be added, the administrator will create a new profile for them, which will include:

Unique login ID
Name,
Role
Contact information
MODULE 2: ORDER MANAGEMENT
This module will include a user-friendly interface for managing orders within the kitchen. Each order will have a unique ID, which will be used to track its progress and ensure accuracy. When an order is received, its initial status will be "in preparation". The system will display the order details, including:

Id order
Time of the order
Table number
Products ordered
Respective quantities of each product
Order´s status ("in preparation", "prepared")
The average preparation time for each product will be stored in the system, allowing staff to estimate when each order will be ready. Once all products in the order are ready, the status will change to "prepared" and the order can be delivered to the customer. The system will also allow staff to view a summary of all orders currently in progress, including their status, estimated time of completion, and any special requests.

MODULE 3: TABLE MANAGEMENT
This module will focus on managing the tables in the restaurant, including their status and availability. A visual map of the restaurant's layout will be displayed, with icons representing each table. We will need the number of the tables and the disposition of each one on the restaurant. Clicking on a table icon will bring up a window with information about the table's orders, such as the products ordered, the status of the orders, and any special requests.

The system will allow staff to view the status of multiple tables at once, perhaps in a table or grid format that summarizes the status of each table. TODO: Look in depth how to use Canvas in Android [https://developer.android.com/.../Canvas](https://developer.android.com/reference/android/graphics/Canvas). This will enable staff to quickly see which tables need attention and to keep track of table availability.

MODULE 4: TAKE-AWAYS
Thoughts ??? If we have time, I think it will be a great addition to the web version jeje.

I'm working on a sketch of the interfaces. When I have something more solid, I will upload it :)

# Server perspective: By jkutkut
## Project description:
EatUp is a restaurant tool to automate the ordering process.

**Note**: This document describes all the services that can be implemented in this project. This is **not** a description of all the features this project will have nor the way they will be added. This is just an initial analysis of the project.

**TL;DR**: This project allows to add services on the fly and allows to dimension the project features to the needs of the restaurant.

## Project Philosophy:
- Modular structure.
- Dockerized services.
- Standard REST API.
- Documentation is key.
- Development planning is key.

## Project structure:
The project will consist of a backend and multiple-independent frontend services.

### Backend:
- Rest API
- Persistent data
  - SQL database
- Public file server
  - Images

### Services
- Order service
- Kitchen service
- Staff service
- Setup service

#### Staff service:
Allows to manage the clients in the restaurant.

- Generate a new client: unique id in an available location.
- End service of a client: Create the bill.
- Gets notified when an order is ready.

#### Order service:
Menu to select the dishes and drinks. The order is sent to the kitchen service.

- Requires a client id.
- Order items:
  - Multiple dishes / drinks of the same type.
  - Multiple orders at the same time.
- Allow multiple orders.

#### Kitchen service:
Queues the orders and notifies the staff service when the order is ready.

- Queues the orders.
- Notifies the staff service when the order is ready.
- Removes the order from the queue when the order is ready.

**Note**: This service can be integrated in the staff service.

#### Setup service:
Creates all the things needed to start running the restaurant.

- Layout editor.
- Product editor.
- Services handler.

### Application graph:

```mermaid
stateDiagram-v2
  [*] --> setup
  state setup {
    layout_editor
    product_editor
    services_handler
  }
  setup --> EatUp
  state EatUp {
    state backend {
      [*] --> rest_api
      rest_api --> public_file_server
      rest_api --> sql_database
    }
    
    state order_service {
      generate_orders
    }

    state staff_service {
      client_manager
      bill_generator
    }

    state kitchen_service {
      orders_queue
    }

    backend --> order_service
    backend --> kitchen_service
    backend --> staff_service
  }
```

## Project development plan:
### Project development plan philosophy:
- Implement the services according to the importance of the service.
- Do not implement a low priority service if a high priority service is not implemented.
- The high priorities features in a low priority service can be implemented independently until the service is implemented.

### Project development plan:
```mermaid
stateDiagram-v2
  [*] --> backend
  [*] --> order_service
  backend --> setup_service
  order_service --> staff_service
  staff_service --> kitchen_service
```

#### v0.1:
- Create project structure.

#### v0.2:
- Define all the features the project will have in `v1.0`, while not forgetting the features that can be implemented in the future.
- Backend:
  - Define DB structure.
- Order service App:
  - List elements form backend needed to implement the service.

#### v0.3:
- Backend:
  - Define the REST API structure.
  - Create the DB structure.
- Order service App:
  - Define interfaces.

#### v0.4:
- Backend:
  - Implement the basic REST API using data from the DB.
- Order service App:
  - Implement the interfaces.

#### v0.5:
- Backend:
  - Implement tools to setup the project on other devices.
- Order service App:
  - Implement the logic.

#### v1.0: **Minimum viable product**
Stable version with all the previous features implemented and tested.

#### v1.1:
- Staff service:
  - Define the scope of the service:
    - Is the kitchen service needed or should be integrated here?
  - Define interfaces.

#### v1.2:
- Backend:
  - Implement the REST API for the staff service.
- Staff service App:
  - Implement the interfaces.

#### v1.3: **New features**
- Staff service App:
  - Implement the logic.
  - Test the service.

#### v1.4: **New features**
- Graphic setup service?
- Takeaways?
- Time to prepare the dishes?
- WebApp?