cyntaria / constructionerp-backend Goto Github PK

Summary

As a contractor, I should be able to create laborer accounts, so that I can manage them on projects.

Acceptance Criteria

GIVEN an contractor is creating a laborer account in the desktop app
WHEN the app hits the /laborers endpoint with a valid POST request, containing:

• first_name
• last_name
• hired_date
• contact
• contractor_id (from #3)

THEN the app should receive a status 201
AND in the response, the following information should be returned:

• headers
• laborer profile

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    "first_name": "...",
    "affected_rows": 1,
     ....
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

{notes for QA, with examples if applicable}

Summary

As a contractor, I should be able to update the details of a laborer, so that I can remove old or inconsistent laborer records.

Acceptance Criteria

GIVEN a contractor is editing a laborer in the desktop app
WHEN the app hits the laborers/:id endpoint with a valid PATCH request, containing:-
The path parameter:

• :id, the unique id of the laborer whose details are edited.

And any of the following body parameters:

• first_name
• last_name
• hired_date
• contact

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• header message indicating update operation success

Sample Request/Sample Response

headers: {
    error: 0,
    message: "The specified item was updated successfully"
}
body: {}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario: PATCH request is successful

1. Update a laborer with a PATCH request to /laborers/:id endpoint
2. A subsequent GET request to /laborers/:id endpoint should return the laborer profile with the updated information i.e. matching the initially sent body.

Description

This epic is a sub goal of the epic for Milestones API and provides information regarding materials. This epic requires few endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This API impacts our project management module as without materials we can't work on milestones. We want to be able to see all possible materials to choose from while ordering in milestones. However, it is not necessary implement before the Milestone Stages API.

Hypothesis

The following is true by the end of this API

• We can query possible materials
• We can manage materials

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Materials #59
• GET A Single Material #60
• POST A New Material #61
• PATCH A Material #62
• DELETE A Material #63
• Documentation For Each Endpoint
• Tests For Each Endpoint

Stakeholders

None

Timeline

1 week is needed to setup all the foundation, along with testing and documentation. No blockers expected.

Summary

As a on-site manager, I should be able to login, so that I can access the features of this ERP

Acceptance Criteria

GIVEN a on-site manager is logging in in the mobile app
WHEN the app hits the auth/login endpoint with a valid request, containing:

• email
• password

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• user profile
• authorization token

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    first_name: "...",
    ...
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

• The response should omit the password from the profile

Testing Notes

{notes for QA, with examples if applicable}

Summary

As a contractor, I should be able to login, so that I can access the features of this ERP

Acceptance Criteria

GIVEN a contractor is logging in in the desktop app
WHEN the app hits the auth/login endpoint with a valid request, containing:

• email
• password

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• user profile
• authorization token

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    first_name: "...",
    ...
}

Resources

• Development URL: [Here goes a URL to the feature on development API];
• Production URL: [Here goes a URL to the feature on production API];

Dev Notes

[Some complementary notes if necessary:]

• The response should omit the password from the profile

Testing Notes

[notes for QA, with examples if applicable]

Summary

As a contractor, I should be able to search for laborers using the name, so that I can view their details.

Acceptance Criteria

GIVEN an contractor is searching for laborers in the desktop app
WHEN the app hits the /laborers endpoint with a valid GET request, containing:
the query parameters:

• name=starts_with, for getting a filtered subset of laborers based on their names.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• list of laborers' profiles

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: [
    {
        id: 0,
        ....
    },
    ....
]

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

{notes for QA, with examples if applicable}

Summary

As a contractor, I should be able to get all possible roles, so that I can assign one while creating a person/laborer account.

Acceptance Criteria

Scenario: Search for all possible roles

GIVEN an contractor is requesting all possible roles in the desktop app
WHEN the app hits the /roles endpoint with a valid GET request
THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• list of roles

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: [
    {
        role_id: 0,
        role: "contractor"
        role_type: "app_user"
    },
    {
        role_id: 5,
        role: "plumber"
        role_type: "laborer"
    },
    ....
]

Scenario: Search for all roles by role type

GIVEN an contractor is requesting all roles for a role type in the desktop app
WHEN the app hits the /roles endpoint with a valid GET request containing the query parameters:

• role_type="type_enum", where type_enum is one of [app_user, laborer]

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• list of roles having that role type

Sample Request/Sample Response
For query parameter role_type=app_user:

headers: {
    error: 0,
    message: "..."
}
body: [
    {
        role_id: 0,
        role: "contractor"
        role_type: "app_user"
    },
    {
        role_id: 5,
        role: "inspector"
        role_type: "app_user"
    },
    ....
]

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

{notes for QA, with examples if applicable}

Summary

As a contractor, I should be able to get all possible rate types, so that I can choose one while renting equipment.

Acceptance Criteria

GIVEN an contractor is requesting all possible rate types in the desktop app
WHEN the app hits the /rate-types endpoint with a valid GET request
THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• list of rate types

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: [
    {
        rate_type_id: 0,
        rate_type: "hourly"
    },
    {
        rate_type_id: 1,
        rate_type: "daily"
    },
    ....
]

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

This endpoint is going to be accessible and work the same way for the product owner as well.

Testing Notes

{notes for QA, with examples if applicable}

Summary

As a product owner, I should be able to delete a label, so that I can remove old or inconsistent labels.

Acceptance Criteria

GIVEN a product owner is deleting a label in the desktop app
WHEN the app hits the labels/:id endpoint with a valid DELETE request, containing the path parameter:

• :id, the unique id of the label being removed.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• header message indicating delete operation success

Sample Request/Sample Response

headers: {
    error: 0,
    message: "The specified item was deleted successfully"
}
body: {}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario 1: DELETE request is successful:

1. Create a new permission with a POST request to /labels endpoint.
2. With the id returned from the POST, make a DELETE request to /labels/:id endpoint.
3. A subsequent GET request to /labels/:id endpoint should return a 404 not found status code.

Scenario 2: DELETE request is forbidden:

1. Make a DELETE request to /labels/:id endpoint using a contractor account token.
2. Ensure the endpoint returns a 403 forbidden status code.

Summary

As a product owner, I should be able to create permissions, so that I can assign them to persons to control modules' access.

Acceptance Criteria

GIVEN an product owner is creating a permissions in the desktop app
WHEN the app hits the /permissions endpoint with a valid POST request, containing:

• permission

THEN the app should receive a status 201
AND in the response, the following information should be returned:

• headers
• permission id

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    "perm_id": "...",
    "affected_rows": 1
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario: POST request is successful

1. Create a new role with a POST request to /permissions endpoint and ensure a 201 status code is returned.
2. Use the id returned by the response in a subsequent GET request to /permissions/:id endpoint and ensure a 200 status code is returned.
3. Ensure the response contains a permission with the correct information i.e. matching the initially sent body.

Scenario: POST request is incorrect

1. Send a POST request to /permissions endpoint with an incorrect key name in the body
2. Ensure a 422 status code is returned
3. And the response headers' code parameter should contain an error pointing out failed validation.

Summary

As a contractor, I should be able to delete a laborer, so that I can remove old or inconsistent laborer records.

Acceptance Criteria

GIVEN a contractor is deleting a laborer in the desktop app
WHEN the app hits the laborers/:id endpoint with a valid DELETE request, containing the path parameter:

• :id, the unique id of the laborer whose details are needed.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• header message indicating delete operation success

Sample Request/Sample Response

headers: {
    error: 0,
    message: "The specified item was deleted sucessfully"
}
body: {}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

A typical test case for a DELETE request would look like this:

1. Create a new laborer with a POST request to /laborers endpoint
2. With the id returned from the POST, make a DELETE request to /laborers/:id endpoint
3. A subsequent GET request to /laborers/:id endpoint should return a 404 not found status code.

Description

This epic is a sub goal of the epic for Persons API and provides information regarding roles. This epic requires few endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to see all possible roles so that we can assign one to a person during account signup. This is the 1st API that should be worked on under Persons API, after Authentication API is complete.

Hypothesis

The following is true by the end of this API

• We can query all possible roles
• We can query roles based on role type
• We can manage roles

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Roles #33
• GET All Role Types 🔒 #69
• GET A Single Roles #34
• POST A New Role 🔒 #35
• PATCH A Role 🔒 #36
• DELETE A Role 🔒 #37
• Documentation For Each Endpoint
• Tests For Each Endpoint

Note: 🔒 symbol indicates the route is protected and accessible to product owner only

Stakeholders

None

Notes

A single role can have one of the following role types:

• app_user, used for contractors, inspectors, home owners etc.
• laborer, used for plumbers, electricians, carpenter etc.

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a sub goal of the epic for Equipment API and provides information regarding rate types. This epic requires few endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to see all possible rate types so that we can assign a rate during equipment rental in milestones. However, it is not necessary until to implement this until we are working on the Equipment API.

Hypothesis

The following is true by the end of this API

• We can query possible rate types
• We can manage rate types

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Rate Types #49
• GET A Single Rate Type #50
• POST A New Rate Type 🔒 #51
• PATCH A Rate Type 🔒 #52
• DELETE A Rate Type 🔒 #53
• Documentation For Each Endpoint
• Tests For Each Endpoint

Note: 🔒 symbol indicates the route is protected and accessible to product owner only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Summary

As a home owner, I should be able to login, so that I can access the reports of my projects

Acceptance Criteria

GIVEN a home owner is logging in in the mobile app
WHEN the app hits the auth/login endpoint with a valid request, containing:

• email
• password

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• user profile
• authorization token

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    first_name: "...",
    ...
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

• The response should omit the password from the profile

Testing Notes

{notes for QA, with examples if applicable}

Summary

As a contractor, I should be able to get all possible labels, so that I can assign them to a milestone to describe its scope of work.

Acceptance Criteria

GIVEN an contractor is requesting all possible labels in the desktop app
WHEN the app hits the /labels endpoint with a valid GET request
THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• list of labels

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: [
    {
        label_id: 0,
        label: "foundation"
    },
    {
        label_id: 1,
        label: "basement"
    },
    ....
]

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

This endpoint is going to be accessible and work the same way for the product owner as well.

Testing Notes

{notes for QA, with examples if applicable}

Summary

As a product owner, I should be able to get all possible permissions, so that I can assign them to a person to control their access to modules.

Acceptance Criteria

Scenario: Search for all possible roles

GIVEN an product owner is requesting all possible permissions in the desktop app
WHEN the app hits the /permissions endpoint with a valid GET request
THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• list of permissions

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: [
    {
        perm_id: 0,
        permission: "read"
    },
    {
        perm_id: 5,
        permission: "write"
    },
    ....
]

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

{notes for QA, with examples if applicable}

Summary

As a product owner, I should be able to signup, so that I can access features of this ERP.

Acceptance Criteria

GIVEN a product owner signs up in the desktop app
WHEN the app hits the auth/signup endpoint with a valid request, containing:

• first_name
• last_name
• email
• password

THEN the app should receive a status 201
AND in the response, the following information should be returned:

• headers
• user profile
• authorization token

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    first_name: "...",
    ...
    token: "....",
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

• The response should omit the password from the profile
• This endpoint should be guarded and used only for product owner

Testing Notes

{notes for QA, with examples if applicable}

Description

This epic is a goal of the larger epic of Milestones API and contains functionality for equipment rentals in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This epic is a sub part of the Milestones API and is needed to provide management of equipment under a milestone. However, it is not necessary for all milestones to require rented equipment so this API can be pushed towards the end.

Hypothesis

The API must provide management of equipment under a milestone. This epic is considered complete when the following features are complete:

• Management and information of equipment
• Equipment Types
• #13
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Equipment #64
• GET All Equipment Types #70
• GET A Single Equipment #65
• POST A New Equipment #66
• PATCH A Equipment #67
• DELETE A Equipment #68

Stakeholders

None

Timeline

3 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a sub goal of the epic for Payments API and provides information regarding payment types. This epic requires few endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to see all possible reasons for a payment so that we can choose a type as reason during payment in milestones. However, it is not necessary until to implement this till we're working on the Payments API.

Hypothesis

The following is true by the end of this API

• We can query possible payment types
• We can manage payment types

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Payment Types #54
• GET A Single Payment Type #55
• POST A New Payment Type 🔒 #56
• PATCH A Payment Type 🔒 #57
• DELETE A Payment Type 🔒 #58
• Documentation For Each Endpoint
• Tests For Each Endpoint

Note: 🔒 symbol indicates the route is protected and accessible to product owner only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a sub goal of the epic for Permissions API and provides information regarding types of permissions. This epic requires few endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to see all possible permissions so that we can assign to a person for access control. This is the 2nd API that should be worked on under Persons API, after Authentication API is complete.

Hypothesis

The following is true by the end of this API

• We can query possible permissions
• We can manage permissions

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Permissions 🔒 #42
• GET A Single Permissions 🔒 #41
• POST A New Permission 🔒 #38
• PATCH A Permission 🔒 #39
• DELETE A Permission 🔒 #40
• Documentation For Each Endpoint
• Tests For Each Endpoint

Note: 🔒 symbol indicates the route is protected and accessible to product owner only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Summary

As a contractor, I should be able to get details of a laborer, so that I can view his profile and assign him work.

Acceptance Criteria

GIVEN a contractor is requesting details of a laborer in the desktop app
WHEN the app hits the laborers/:id endpoint with a valid GET request, containing the path parameter:

• :id, the unique id of the laborer whose details are needed.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• laborer's profile

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    id: 0,
    first_name: "...."
    ....
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

GIVEN a contractor is requesting details of a laborer in the desktop app
WHEN the laborers/:id` endpoint receives valid GET request, containing the path parameter:

• :id

THEN the app should receive a status 200
AND the {id} in the body should be same as the :id in the path parameter

Summary

As an product owner, I should be able to login, so that I can access the features of this ERP

Acceptance Criteria

GIVEN a product owner is logging in in the desktop app
WHEN the app hits the auth/login endpoint with a valid request, containing:

• email
• password

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• user profile
• authorization token

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    first_name: "...",
    ...
    token: "....",
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

• The response should omit the password from the profile

Testing Notes

{notes for QA, with examples if applicable}

Summary

As a contractor, I should be able to get details of a single role, so that I can understand which person is it for.

Acceptance Criteria

GIVEN a contractor is requesting details of a role in the desktop app
WHEN the app hits the roles/:id endpoint with a valid GET request, containing the path parameter:

• :id, the unique id of the role whose details are needed.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• role details

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    role_id: 0,
    role: "home_owner"
    role_type: "app_user"
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

GIVEN a contractor is requesting details of a role in the desktop app
WHEN the app hits the roles/:id endpoint with a valid GET request, containing the path parameter:

• :id

THEN the app should receive a status 200
AND the {id} in the body should be same as the :id in the path parameter

Summary

As a product owner, I should be able to get details of a single permission, so that I can understand what is the scope of the access it allows.

Acceptance Criteria

GIVEN a product owner is requesting details of a permission in the desktop app
WHEN the app hits the permissions/:id endpoint with a valid GET request, containing the path parameter:

• :id, the unique id of the permission whose details are needed.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• permission details

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    perm_id: 0,
    permission: "write"
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

GIVEN a product owner is requesting details of a permission in the desktop app
WHEN the app hits the permissions/:id endpoint with a valid GET request, containing the path parameter:

• :id

THEN the app should receive a status 200
AND the {id} in the body should be same as the :id in the path parameter

Summary

As a product owner, I should be able to create roles, so that I can assign them to persons/laborers.

Acceptance Criteria

GIVEN an product owner is creating a role in the desktop app
WHEN the app hits the /roles endpoint with a valid POST request, containing:

• role
• role_type, any one from [app_user,laborer]

THEN the app should receive a status 201
AND in the response, the following information should be returned:

• headers
• role id

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    "role_id": "0",
    "affected_rows": 1
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario: POST request is successful

1. Create a new role with a POST request to /roles endpoint and ensure a 201 status code is returned.
2. Use the id returned by the response in a subsequent GET request to /roles/:id endpoint and ensure a 200 status code is returned.
3. Ensure the response contains a role with the correct information i.e. matching the initially sent body.

Scenario: POST request is incorrect

1. Send a POST request to /roles endpoint with the role_type containing a value not in [app_user,laborer].
2. Ensure a 422 status code is returned
3. And the response headers' code parameter should contain an error pointing out failed validation.

Description

This epic is a goal of the larger epic of REST API and contains functionality for project management in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This epic is a core part of the overall project.

Hypothesis

The API must provide management and information for projects. This epic is considered complete when the following features are complete:

• Project Management
• Project Roles #24
• Project Payments #12
• Project Milestone #8
• Project Equipment #11
• Project Material #10

Acceptance criteria and must have scope

We must have Authentication and Persons API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Projects #81
• GET Single Project #80
• GET A Project's Milestones #82
• GET A Project's Roles #83
• GET A Project's Payments #75
• GET A Project's Materials #84
• POST A New Project #76
• PATCH A Project #78 , #79
• DELETE A Project #77
• Documentation
• Tests

Stakeholders

None

Timeline

2 weeks are needed to setup all the foundation, along with testing and documentation plus an additional week to test the merged sub epics. The structure of materials and payments endpoint might change in order to reduce joins to improve search queries.

Summary

As a product owner, I should be able to delete a permission, so that I can remove old or inconsistent permissions.

Acceptance Criteria

GIVEN a product owner is deleting a permission in the desktop app
WHEN the app hits the permissions/:id endpoint with a valid DELETE request, containing the path parameter:

• :id, the unique id of the permission being removed.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• header message indicating delete operation success

Sample Request/Sample Response

headers: {
    error: 0,
    message: "The specified item was deleted successfully"
}
body: {}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

A typical test case for a DELETE request would look like this:

1. Create a new permission with a POST request to /permissions endpoint
2. With the id returned from the POST, make a DELETE request to /permissions/:id endpoint
3. A subsequent GET request to /permissions/:id endpoint should return a 404 not found status code.

Description

This epic is a goal of the larger epic of Milestones API and contains functionality for label assignment in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This epic is a sub part of the Milestones API.

Hypothesis

The API must provide management of labels. This epic is considered complete when the following features are complete:

• Labels Management
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Labels #43
• GET A Single Label #45
• POST A New Label 🔒 #48
• PATCH A Label 🔒 #47
• DELETE A Label 🔒 #46

Note: 🔒 symbol indicates the route is protected and accessible to product owner only

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Summary

As a product owner, I should be able to create accounts, so that I can signup contractors, their workforce and home owners.

Acceptance Criteria

GIVEN an product owner is creating a user account in the desktop app
WHEN the app hits the /persons endpoint with a valid POST request, containing:

• first_name
• last_name
• email_address
• password
• contact
• address
• role_id (from #24)

THEN the app should receive a status 201
AND in the response, the following information should be returned:

• headers
• user profile
• authorization token

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    first_name: "...",
    ...
    token: "..."
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

• The response should omit the password from the profile.
• Their should be a check on the role type to ensure only the product owner can create contractor accounts.

Testing Notes

Scenario: Somebody other than a product owner sends request for a contractor account

GIVEN when a request arrives for creating an account
AND the role id belongs to the type contractor
THEN the app should receive a status 403 (Forbidden)
AND in the response, the following information should be returned:

• headers with the error message

Sample Request/Sample Response

headers: {
    error: 1,
    code: "SOME_ERROR_KEY"
    message: "..."
}
body: {}

Summary

As an inspector, I should be able to login, so that I can access the features of this ERP

Acceptance Criteria

GIVEN an inspector is logging in in the mobile app
WHEN the app hits the auth/login endpoint with a valid request, containing:

• email
• password

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• user profile
• authorization token

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    first_name: "...",
    ...
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

• The response should omit the password from the profile

Testing Notes

{notes for QA, with examples if applicable}

Summary

As a contractor, I should be able to get details of a single label, so that I can understand what kind of work it describes/represents.

Acceptance Criteria

GIVEN a contractor is requesting details of a label in the desktop app
WHEN the app hits the labels/:id endpoint with a valid GET request, containing the path parameter:

• :id, the unique id of the label for which the details are needed.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• label details

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    label_id: 0,
    label: "interior"
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

This endpoint is accessible by and serves the product owner in the same way.

Testing Notes

GIVEN a contractor is requesting details of a label in the desktop app
WHEN the app hits the labels/:id endpoint with a valid GET request, containing the path parameter:

• :id

THEN the app should receive a status 200
AND the {id} in the body should be same as the :id in the path parameter

Summary

As a product owner, I should be able to update the details of a role, so that I can fix old or inconsistent roles.

Acceptance Criteria

GIVEN a product owner is editing a role in the desktop app
WHEN the app hits the roles/:id endpoint with a valid PATCH request, containing:-
The path parameter:

• :id, the unique id of the role whose details are edited.

And any of the following body parameters:

• role
• role_type, any of the following [app_user, laborer]

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• header message indicating update operation success

Sample Request/Sample Response

headers: {
    error: 0,
    message: "The specified item was updated successfully"
}
body: {}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario: PATCH request is successful

1. Update a role with a PATCH request to /roles/:id endpoint
2. A subsequent GET request to /roles/:id endpoint should return the role details with the updated information i.e. matching the initially sent body.

Description

This epic is a sub goal of the epic for Milestones API and provides management and information of stages in a milestone. This epic requires few endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This API impacts our project management module as without stages we can't progress the milestones. We want to be able to set different criteria stages in milestones to track progress. It is the first thing that we need to work on under Milestones API.

Hypothesis

The following is true by the end of this API

• We can query possible stages
• We can manage stages

Acceptance criteria and must have scope

We must have Authentication and Persons API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Stages #90 #91
• GET A Single Stage #89
• POST A New Stage #85
• PATCH A Stage #87 #88
• DELETE A Stage #86
• Documentation For Each Endpoint
• Tests For Each Endpoint

Stakeholders

None

Timeline

10 days are needed to setup all the foundation, along with testing and documentation. Using of project role id instead of person permission id might be something that will change and can cause a few endpoints to be refactored as well as their tests

Description

This epic is a goal of the larger epic of REST API and contains functionality for persons in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This epic is a high impact goal as it provided the foundation for other API Epics.

Hypothesis

The API must provide person profile features, roles and permissions. This epic is considered complete when the following features are complete:

• Person roles. #24
• Person permissions. #26
• Person profile.
• Documentation
• Tests

Acceptance criteria and must have scope

We need Authentication API to be complete only for the endpoints of this API, not for some internal functionality. This API only focuses on user related tasks. It should make sure the entire Roles API and Permissions API is complete as well.

Stakeholders

None

Timeline

2 weeks are needed to setup all the foundation, along with testing and documentation. No blockers so far

Summary

As a product owner, I should be able to delete a role, so that I can remove old or inconsistent roles.

Acceptance Criteria

GIVEN a product owner is deleting a role in the desktop app
WHEN the app hits the roles/:id endpoint with a valid DELETE request, containing the path parameter:

• :id, the unique id of the role being removed.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• header message indicating delete operation success

Sample Request/Sample Response

headers: {
    error: 0,
    message: "The specified item was deleted successfully"
}
body: {}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

A typical test case for a DELETE request would look like this:

1. Create a new role with a POST request to /roles endpoint
2. With the id returned from the POST, make a DELETE request to /roles/:id endpoint
3. A subsequent GET request to /roles/:id endpoint should return a 404 not found status code.

Description

This epic is a goal of the larger epic of REST API and contains functionality for authentication in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This epic is a high impact goal as it provided the foundation for other API Epics.

Hypothesis

The API must provide person authentication, request validation and request verification. This epic is considered complete when the following features are complete:

• Private API KEY/OAuth2 verification.
• Authorization token for each request.
• Person authentication procedures.
• Role based request access for each user.
• Documentation
• Tests

Acceptance criteria and must have scope

We must have person types and roles setup to control permissions in this API. This API only focuses on auth related tasks for persons, requests and apps.

Stakeholders

None

Timeline

2 weeks are needed to setup all the foundation, along with testing and documentation. No blockers so far

Description

This epic is a sub goal of the epic for Projects API and provides functionality surrounding project milestones. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This API impacts our project management module as without milestones we can't create tasks for our project and we can't proceed. We want to be able to divide a project into milestones each with it's own materials, stages, payments and equipment. We can track what labor is working on each milestone daily. We can assign labels to a milestone to indicate what is it's scope. We should work on this immediately after setting up Projects API.

Hypothesis

The following is true by the end of this API

• We can query/manage possible milestones of a project
• We can query/manage stages in a milestone #9
• We can query/manage ordered materials in a milestone #10
• We can query/manage rented equipment in a milestone #11
• We can query/manage payments in a milestone #12
• We can query/manage labor activity on a milestone #4
• We can query/manage labels on a milestone #7

Acceptance criteria and must have scope

We must have Authentication, Projects and Labors API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Milestones
• GET A Milestone's Stages
• GET A Milestone's Labor
• GET A Milestone's Labels
• GET A Milestone's Payments #71
• GET A Milestone's Rented Equipment
• GET A Milestone's Ordered Materials
• GET A Single Milestone
• POST A New Milestone
• PATCH A Milestone
• DELETE A Milestone
• Documentation For Each Endpoint
• Tests For Each Endpoint

Stakeholders

None

Timeline

5 weeks are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Summary

As a person, I should be able to change my password, so that I can choose an updated one for security reasons.

Acceptance Criteria

GIVEN a person is logged in in the desktop app
AND they change their password
WHEN the app hits the auth/change_password endpoint with a valid request, containing:

• email
• old_password
• new_password

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• rows updated

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    rows_updated: 1,
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

{notes for QA, with examples if applicable}

Description

This epic is a sub goal of the Complete REST API and provides information regarding permissions. This epic requires few endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to see all possible permissions so that we can assign to a person during account access setup. This is the 1st API that should be worked on after Persons API is complete.

Hypothesis

The following is true by the end of this API

• We can query possible permissions
• We can manage permissions ( Product Owner ONLY )

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Permissions
• GET A Single Permissions
• POST A New Permissions (Product Owner ONLY)
• PATCH A Permissions (PO ONLY)
• DELETE A Permissions (PO ONLY)
• Documentation For Each Endpoint
• Tests For Each Endpoint

Stakeholders

None

Timeline

2 days are needed to setup all the foundation, along with testing and documentation. No blockers expected.

Description

This epic is a large component of the overall project and is used to communicate between our server and our apps. This epic needs to prepare a working, fully functional REST API with multiple endpoints for use cases.

Initiative / goal

It is high impact since it used to communicate between our server and our apps so without this the project can not work.

Hypothesis

A documented API is received in the end containing all functionalities for the project. These are the endpoint collections it must have:

• #2
• #3
• #4
• #6
• #7
• #8
• #9
• #10
• #11
• #12
• #13
• #14
• Health Check

Acceptance criteria and must have scope

We need documentation, tested API endpoint URLs, Postman collection for each endpoints and a backup of the database schema and data.

Stakeholders

@diablo-shotgun @sfurqan2 are members of the engineering team who will verify the completion.

Timeline

3 months is the approximate timeline, a working deployable server is needed for the API as well as the DB instance. Currently, there are no identified blockers.

Summary

As a contractor, I should be able to create accounts, so that I can create user accounts for inspectors and on-site managers.

Acceptance Criteria

GIVEN an contractor is creating a user account in the desktop app
WHEN the app hits the /persons endpoint with a valid POST request, containing:

• first_name
• last_name
• email_address
• password
• contact
• address
• role_id (from #24)

THEN the app should receive a status 201
AND in the response, the following information should be returned:

• headers
• user profile
• authorization token

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    first_name: "...",
    ...
    token: "..."
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

• The response should omit the password from the profile

Testing Notes

{notes for QA, with examples if applicable}

Summary

As a contractor, I should be able to get details of a single rate type, so that I can understand what kind of rate it describes/represents.

Acceptance Criteria

GIVEN a contractor is requesting details of a rate type in the desktop app
WHEN the app hits the rate-types/:id endpoint with a valid GET request, containing the path parameter:

• :id, the unique id of the rate type for which the details are needed.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• rate type details

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    rate_type_id: 0,
    rate_type: "hourly"
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

This endpoint is accessible by and serves the product owner in the same way.

Testing Notes

GIVEN a contractor is requesting details of a rate type in the desktop app
WHEN the app hits the rate-types/:id endpoint with a valid GET request, containing the path parameter:

• :id

THEN the app should receive a status 200
AND the {id} in the body should be same as the :id in the path parameter

Summary

As a product owner, I should be able to update the details of a label, so that I can fix old or inconsistent labels.

Acceptance Criteria

GIVEN a product owner is editing a label in the desktop app
WHEN the app hits the labels/:id endpoint with a valid PATCH request, containing:-
The path parameter:

• :id, the unique id of the label of which the details are edited.

And any of the following body parameters:

• permission

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• header message indicating update operation success

Sample Request/Sample Response

headers: {
    error: 0,
    message: "The specified item was updated successfully"
}
body: {}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario 1: PATCH request is successful

1. Update a label with a PATCH request to /labels/:id endpoint
2. A subsequent GET request to /labels/:id endpoint should return a status code 200 and the permission details with the updated information i.e. matching the initially sent body.

Scenario 2: PATCH request is forbidden

1. Send a PATCH request to /labels/:id endpoint using a contractor account token.
2. Ensure the response returns a 403 forbidden status code.

Summary

As a person, I should be able to reset my password, so that I can gain access to my account.

Acceptance Criteria

Scenario 1: Person requests a password reset code

GIVEN a person is choosing forget password in the desktop app
WHEN the app hits the auth/forgot_password endpoint with a valid request, containing:

• email

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• OTP sent message

Sample Request/Sample Response

headers: {
    error: 0,
    message: "OTP sent to mail"
}
body: {}

Scenario 2: Person requests otp verification

GIVEN a person is verifying otp in the desktop app
WHEN the app hits the auth/verify_otp endpoint with a valid request, containing:

• 6 digit OTP

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• OTP verified message

Sample Request/Sample Response

headers: {
    error: 0,
    message: "OTP verified"
}
body: {}

Scenario 3: Person requests password reset

GIVEN a person is resetting password in the desktop app
WHEN the app hits the auth/reset_password endpoint with a valid request, containing:

• email
• new_password

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• password reset successful

Sample Request/Sample Response

headers: {
    error: 0,
    message: "Password Reset Successful"
}
body: {}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

{notes for QA, with examples if applicable}

Description

This epic is a goal of the larger epic of REST API and contains functionality for laborers management in our project. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

This epic is is essential to the working of the entire project but has to be implemented near the end of the REST API Epic.

Hypothesis

The API must provide management for laborers. This epic is considered complete when the following features are complete:

• Laborer information
• Laborer assigning
• Laborer management
• Documentation
• Tests

Acceptance criteria and must have scope

We must have Authentication and Users API setup. In the end we need to have a collection of following endpoints:

• GET All Laborers #29
• GET A Single Laborer #30
• POST A New Laborer #28
• PATCH A Laborer #32
• DELETE A Laborer #31

Stakeholders

None

Timeline

1 weeks are needed to setup all the foundation, along with testing and documentation. No blockers so far

Summary

As a product owner, I should be able to update the details of a permission, so that I can fix old or inconsistent permissions.

Acceptance Criteria

GIVEN a product owner is editing a permission in the desktop app
WHEN the app hits the permissions/:id endpoint with a valid PATCH request, containing:-
The path parameter:

• :id, the unique id of the permission whose details are edited.

And any of the following body parameters:

• permission

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• header message indicating update operation success

Sample Request/Sample Response

headers: {
    error: 0,
    message: "The specified item was updated successfully"
}
body: {}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario: PATCH request is successful

1. Update a permission with a PATCH request to /permissions/:id endpoint
2. A subsequent GET request to /permissions/:id endpoint should return the permission details with the updated information i.e. matching the initially sent body.

Summary

As a product owner, I should be able to create labels, so that the contractor can assign them to milestones.

Acceptance Criteria

GIVEN an product owner is creating a label in the desktop app
WHEN the app hits the /labels endpoint with a valid POST request, containing:

• label

THEN the app should receive a status 201
AND in the response, the following information should be returned:

• headers
• label id

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    "label_id": "...",
    "affected_rows": 1
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

{Some complementary notes if necessary}

Testing Notes

Scenario 1: POST request is successful

1. Create a new role with a POST request to /labels endpoint and ensure a 201 status code is returned.
2. Use the id returned by the response in a subsequent GET request to /labels/:id endpoint and ensure a 200 status code is returned.
3. Ensure the response contains a label with the correct information i.e. matching the initially sent body.

Scenario 2: POST request is incorrect

1. Send a POST request to /labels endpoint with an incorrect key name in the body
2. Ensure a 422 status code is returned
3. And the response headers' code parameter should contain an error pointing out failed validation.

Scenario 3: POST request is forbidden

1. Send a POST request to /labels endpoint with a contractor account token.
2. Ensure a 403 forbidden status code is returned.
3. And the response headers' code parameter should contain an error pointing out failed access.

Description

This epic is a sub goal of the epic for Milestones API and provides management of payments. This epic requires multiple endpoints to be setup and tested along with their detailed documentation.

Initiative / goal

We want to be able to see all create, manage, retrieve and summarize payments under a milestone. However, it is not necessary until to implement this till all other sub goals of a milestone are complete.

Hypothesis

The following is true by the end of this API

• We can manage payments for a milestone
• We can choose a payment type for a payment. #14

Acceptance criteria and must have scope

We must have Authentication API setup prior to this. In the end we need to have a collection of following endpoints:

• GET All Payments (Temporary - for testing only)
• GET A Single Payment (Temporary - for testing only)
• POST A New Payment #72
• PATCH A Payment #74
• DELETE A Payment #73
• Documentation For Each Endpoint
• Tests For Each Endpoint

Stakeholders

None

Timeline

1 week is needed to setup all the foundation, along with testing and documentation. No blockers expected.

Summary

As a contractor, I should be able to get details of a single label, so that I can understand what kind of work it describes/represents.

Acceptance Criteria

GIVEN a contractor is requesting details of a label in the desktop app
WHEN the app hits the labels/:id endpoint with a valid GET request, containing the path parameter:

• :id, the unique id of the label for which the details are needed.

THEN the app should receive a status 200
AND in the response, the following information should be returned:

• headers
• label details

Sample Request/Sample Response

headers: {
    error: 0,
    message: "..."
}
body: {
    label_id: 0,
    label: "interior"
}

Resources

• Development URL: {Here goes a URL to the feature on development API}
• Production URL: {Here goes a URL to the feature on production API}

Dev Notes

This endpoint is accessible by and serves the product owner in the same way.

Testing Notes

GIVEN a contractor is requesting details of a label in the desktop app
WHEN the app hits the labels/:id endpoint with a valid GET request, containing the path parameter:

• :id

THEN the app should receive a status 200
AND the {id} in the body should be same as the :id in the path parameter