Feature 125/add technologies to project

README.md

@@ -264,7 +264,7 @@ docker run -p 5000:5000 time_tracker_api:local
 
 ## Migrations
 Looking for a DB-agnostic migration tool, the only choice I found was [migrate-anything](https://pypi.org/project/migrate-anything/).
-An specific requirement file was created to run the migrations in `requirements/migrations.txt`. This way we do not mix
+A specific requirement file was created to run the migrations in `requirements/migrations.txt`. This way we do not mix
 any possible vulnerable dependency brought by these dependencies to the environment `prod`. Therefore the dependencies
 to run the migrations shall be installed this way:
 
@@ -274,16 +274,16 @@ pip install -r requirements/migrations.txt
 ```
 
 All the migrations will be handled and created in the python package `migrations`. In order to create a migration we 
-must do it manually (for now) and prefixed by a number, e.g. `migrations/01-initialize-db.py` in order to warranty the 
+must do it manually (for now) and prefixed by a number, e.g. `migrations/01-initialize-db.py` in order to guarantee the 
 order of execution alphabetically.
 Inside every migration there is an `up` and `down` method. The `down` method is executed from the persisted migration in
-the database. Whe a `down` logic that used external dependencies was tested it failed, whilst I put that same logic in 
-the an `up` method it run correctly. In general the library seems to present [design issues](https://github.com/Lieturd/migrate-anything/issues/3).
+the database. When a `down` logic that used external dependencies was tested, it failed; whilst, I put that same logic in 
+the `up` method, it run correctly. In general, the library seems to present [design issues](https://github.com/Lieturd/migrate-anything/issues/3).
 Therefore, it is recommended to apply changes just in one direction: `up`.
 For more information, please check out [some examples](https://github.com/Lieturd/migrate-anything/tree/master/examples) 
-that illustrates the usage of this migration tool.
+that illustrate the usage of this migration tool.
 
-Basically, for running the migrations you must execute
+Basically, for running the migrations you must execute:
 
 ```bash
 migrate-anything migrations

tests/time_tracker_api/projects/projects_namespace_test.py

@@ -12,7 +12,9 @@
     "name": fake.company(),
     "description": fake.paragraph(),
     'customer_id': fake.uuid4(),
-    'project_type_id': fake.uuid4()
+    'project_type_id': fake.uuid4(),
+    'technologies': ["python", "faker", "openapi"]
+
 }
 
 fake_project = ({
@@ -27,7 +29,6 @@ def test_create_project_should_succeed_with_valid_request(client: FlaskClient,
     repository_create_mock = mocker.patch.object(project_dao.repository,
                                                  'create',
                                                  return_value=fake_project)
-
     response = client.post("/projects",
                            headers=valid_header,
                            json=valid_project_data,

time_tracker_api/projects/projects_model.py

@@ -30,6 +30,7 @@ class ProjectCosmosDBModel(CosmosDBModel):
     customer_id: str
     deleted: str
     tenant_id: str
+    technologies: list
 
     def __init__(self, data):
         super(ProjectCosmosDBModel, self).__init__(data)  # pragma: no cover 

time_tracker_api/projects/projects_namespace.py

@@ -39,6 +39,13 @@
         description='Id of the project type it belongs. This allows grouping the projects.',
         example=faker.uuid4(),
     ),
+    'technologies': fields.List(
+        fields.String,
+        title='List of technologies this project involves',
+        required=False,
+        description='List of technologies this project involves',
+        example="['python', 'restplus', 'openapi']",
+    )
 })
 
 project_response_fields = {}