gantt
dateFormat YYYY-MM-DD
axisFormat %W
title GANTT Chart for the Development of a Fullstack Decluttering App for REMONIDS
excludes weekends 2022-10-03 2022-11-01 2022-10-21 2022-10-26 2022-10-27 2022-10-28
section Backend & Database
Schema (mermaid) :done, db_mermaid, 2022-10-18, 3d
Schema (prisma) :done, db_prisma, after db_mermaid, 3d
Backend mock data :done, mockdata, 2022-10-31, 2d
Backend mediator functions :crit, done, api_mediator_functions, 2022-10-18, 8d
section Frontend
transition to using mediator functions :crit, active, refactor_api, after db_prisma after mockdata after api_mediator_functions, 2d
Figma wireframes :done figma_wireframe, 2022-10-18, 5d
refactor styles :active refactor_style, after figma_wireframe, 3d
section Organization
Update call : update1, after refactor_style after refactor_api, 1d
National holidays:
- Monday 03.10.2022 (Week 40) -Day of German Unity
- Tuesday 01.11.2022 (Week 44) -Day of German Unity
Study events (not available for project work):
- Friday 21.10.2022 -Checkpoint 3 (Week 42)
- Wednesday-Friday 26.10.2022-28.10.2022 -Gamejam Hackathon (Week 43)
- Architects: people who devise the "schema" of data layers and "endpoints" of API interfaces. In later stages they help create a development environment for other teams including providing sample data, unit tests, demanding architectural changes (i.e. refactoring), and monitoring code quality overall.
- Designers: people who devise the LoFi wireframes in the beginning of the project. In later stages they do the actual design including the Figma mockups. Upon approval they move to providing the styled components (writing CSS from scratch or using any framework/library they deem appropriate). These people will also look after useability and responsive design, it is a massive job.
- Frontend: people who use React.js or Next.js in any way they deem appropriate to build the logic of the frontend (i.e. browser) application. They are responsible for the offering a great functional experience. Using local storage, form constraints, and a great camera experience on mobile for the inspector user role. The use of any state manager or form validation library is allowed and encouraged.
- Backend: people who use Express, Fastify or any other NodeJS framework to build the backend while implementing the API precisely as designed by the architects.
A person can only make use of the fullstack application by having a user account, which assigns the "user" (i.e. person in charge of the account) to a specific "user role".
Technically speaking, a user role is a collection of user permissions on the app.
Some examples of permissions are:
- The permission to create a new de-cluttering case in the app
- The permission to assign an existing de-cluttering case to a user in the app
- The permission to reject a case that had been assigned to the user by another user in the app
- The permission to delete a user account and all of the cases associated with the user account
Note that when decribing permissions, it is important to maintain a role-agnostic wording (e.g. the user, another user, etc.).
This way, the permissions remain independent from the user roles, allowing us to change the mapping between the two as needed in response to change in the user requirements.
- Manager: is the user role capable of creating new de-cluttering cases
- Inspector: is the user role capable of filling in "inspection information" into a de-cluttering case that he/she is assigned to
- developer rights: Are the user permissions not granted to any user role in the app
- manager rights: Are the user permissions acquired by the manager role, but not the inspector role
- inspector rights: Are the user permissions acquired by both the manager role and the inspector role
Many systems can be modelled as state machines. Despite the name, a system that is modelled as a state machine does not need to be implented in hardware (i.e. as a physical machine). Namely, it is just for us to describe deterministic behavior in a very clear and an unambiguous way.
The fullstack application to be developed have two main types of statefull entitites:
- User accounts
- De-cluttering cases
The behavior of these entities is described using two state diagrams, in the following subsections.
The following diagram illustrates the different states of a user account, regardless of the user role assigned to this account.
stateDiagram-v2
state "USER CREATED" as created
state "USER CONFIRMED" as confirmed
state "USER ACTIVE" as active
state "USER INACTIVE" as inactive
[*] --> created: a user account is created with\nan unconfirmed email address
created --> confirmed: user confirms the email\naddress by opening the link
confirmed --> inactive: user provides password
inactive --> active: user toggles activity in app
active --> inactive: user toggles activity in app
active --> [*]: user is deleted by developer
inactive --> [*]: user is deleted by developer
sequenceDiagram
Note right of Frontend: User enters email and clicks 'register'
Frontend->>+Backend: [API Endpoint] /users/register {email}
Backend->>-Email: [Action] sends email with confirmation link
Note left of Email: User clicks on confirmation link
Email->>+Backend: [API Endpoint] /users/{id}/confirmation?token=xxx
Note right of Backend: Backend checks if token is valid
Backend->>Frontend: HTTP Redirect to Frontend route for expired token
Backend->>-Frontend: HTTP Redirect to Frontend route for continued registration {token}
Note right of Frontend: User fills in user data and password
Frontend->>+Backend: [API Endpoint] /users/{id}/confirm {...data, token}
Backend->>Frontend: Success message
Backend->>-Frontend: Failure message
sequenceDiagram
Note right of Frontend: User enters email and clicks 'forgot password'
Frontend->>+Backend: [API Endpoint] /users/{id}/forgotPassword {email}
Backend->>-Email: [Action] sends email with password reset link
Note left of Email: User clicks on password reset link
Email->>Frontend: HTTP Redirect to Frontend route for password reset
Frontend->>+Backend: [API Endpoint] /users/{id}/validateToken {token}
Note right of Backend: Backend checks if token is valid
Backend->>Frontend: Token is invalid
Note right of Frontend: Frontend display error message (token expired)
Backend->>-Frontend: Token is valid
Frontend->>+Backend: [API Endpoint] /users/{id}/resetPassword {password, token}
Backend->>Frontend: Failure message
Note right of Frontend: Frontend display error message (unexpected error)
Backend->>-Frontend: Success message
Note right of Frontend: Frontend displays success message (password changed)
The following diagram illustrates the different states that a de-cluttering case, and the transitions from and to the different states based on the interactions between the users of the platform and the case in the diagram.
Note that the diagram focusses on the lifecycle of the de-cluttering within the scope of the fullstack application being developed, only. Namely, we are only concerned with the states of the case as it lives through the fullstack application.
stateDiagram-v2
state "CASE CREATED" as created
state "CASE ASSIGNED" as assigned
state "CASE CONFIRMED" as confirmed
state "CASE ONGOING" as ongoing
state "CASE READY" as ready
state "CASE QUOTED" as quoted
state "CASE CLOSED" as closed
[*] --> created: manager creates de-cluttering case
created --> assigned: manager assigns case to one inspector\n(named the assigned inspector or "AI")
assigned --> created: AI(*) declines assignement
assigned --> assigned: manager re-assigns case
assigned --> confirmed: AI(*) accepts assignment
confirmed --> ready: AI(*) fills in\nall information
confirmed --> ongoing: AI(*) fills in some\ninformation
ongoing --> ongoing: AI(*) fills in more\ninformation
ongoing --> ready: AI(*) fills in missing or\nremaining information
ready --> quoted: manager sends quote to household owner
created --> closed: manager\ncloses\ncase
assigned --> closed: manager\ncloses\ncase
confirmed --> closed: manager\ncloses\ncase
ongoing --> closed: manager\ncloses\ncase
ready --> closed: manager\ncloses\ncase
closed --> [*]: quote is closed for whatever reason
quoted --> [*]: quote is accepted or rejected by household owner\n(this is not managed be the fullstack application)
(*): AI stands for the assigned inspector
The starting and ending points of the state diagram (i.e. the two terminal points above) encompass the scope of the fullstack application which is being developed.
Namely, the following things are outside the scope of the fullstack application:
- Getting de-cluttering leads/contacts
- Issuing de-cluttering quotes
- Following up on issued quoted and re-issuing altered quotes
- Payment collection and de-cluttering confirmation
- Planning and execution of the de-cluttering itself
- Any later procedures following the de-cluttering itself
TODO
To be provided using OpenAPI (i.e. Swagger). Find documentation here
This is currently being generated from a declarative .prisma code source.
%%{init: {'theme':'base'}}%%
erDiagram
USERS ||--o{ CASES : create
CASES ||--o{ CASE_ITEMS : contain
CASES o{--|| CASE_STATES : use
CASES o{--|| TYPE_OF_PROPERTIES : use
CASES ||--o{ APPOINTMENTS : "can have"
CASES ||--o{ CASE_HISTORY : "can have"
CASE_HISTORY o{--|| CASE_STATES : use
CASE_HISTORY o{--|| USERS : use
CASE_ITEMS ||--o{ CASE_PHOTOS : "can have"
TRANSITIONS ||--o| TRANSITION_ACCESS: "can have"
TRANSITION_ACCESS o{--o{ USERS: "use"
TRANSITIONS o{--|| CASE_STATES : use
USERS {
int id PK "NOT_NULL"
string username
string email "NOT_NULL"
string hash_password
string role
string state
string token
date_time created_time "NOT_NULL"
date_time confirmed_time
}
CASES {
int id PK "NOT_NULL"
date_time create_time "NOT_NULL"
date_time assigned_time
date_time agreeded_time
string client_first_name
string client_last_name
string client_email "NOT_NULL"
string client_phone "NOT_NULL"
string address "NOT_NULL"
int floor
int elevator
float squaremeters
int quantity
string way_to_property
int type_of_property_id FK
int state_id FK
int manager_id FK
int inspector_id FK
}
CASE_ITEMS{
int id PK "NOT_NULL"
int case_id FK "NOT_NULL"
int room "NOT_NULL"
string room_title
string description
int quantity
}
CASE_PHOTOS{
int id PK
int case_id FK
int room FK
blob photo
}
CASE_STATES{
int id PK "NOT_NULL"
string title "NOT_NULL"
}
TYPE_OF_PROPERTIES{
int id PK "NOT_NULL"
string title "NOT_NULL"
}
APPOINTMENTS{
int id PK "NOT_NULL"
date date "NOT_NULL"
time time_from "NOT_NULL"
time time_to "NOT_NULL"
int case_id FK "NOT_NULL"
}
CASE_HISTORY{
int id PK "NOT_NULL"
date_time time "NOT_NULL"
int case_id FK "NOT_NULL"
int case_state_id FK "NOT_NULL"
int case_new_state_id FK "NOT_NULL"
int user_id FK "NOT_NULL"
string description
jsonb case_data
}
TRANSITIONS{
int id PK "NOT_NULL"
int state_id "NOT_NULL"
int next_state_id "NOT_NULL"
}
TRANSITION_ACCESS{
string role "PK role + transition_id"
int transition_id FK
}