┆Issue is synchronized with this Trello card by Unito
┆Attachments: Design.png

Issue Description

Feature Description:

Currently, admin users have no way of managing Manual EMH Robots programmatically. Providing API endpoints for CRUD operations on EMH Robots would increase our system's usability and make it easier for admins to manage the robots.

User Stories:

As an admin, I want to create a new Manual EMH Robot via an API so that I can automate the process.
As an admin, I want to read the details of a Manual EMH Robot via an API to check its status and other parameters.
As an admin, I want to update the settings of a Manual EMH Robot via an API to make quick adjustments.
As an admin, I want to delete a Manual EMH Robot via an API to remove it from the system when it's no longer needed.

Tasks:

• Design the API specification for CRUD operations for Manual EMH Robots.
• Implement the API endpoints for creating a new Manual EMH Robot.
• Implement the API endpoints for reading the details of a Manual EMH Robot.
• Implement the API endpoints for updating the settings of a Manual EMH Robot.
• Implement the API endpoints for deleting a Manual EMH Robot.
• Write unit tests and integration tests for the new API endpoints.
• Update API documentation to cover these new endpoints.

Acceptance Criteria:

• The API should allow an admin to create a new Manual EMH Robot.
• The API should allow an admin to read the details of an existing Manual EMH Robot.
• The API should allow an admin to update the details of an existing Manual EMH Robot.
• The API should allow an admin to delete an existing Manual EMH Robot.
• All new code should have unit tests and integration tests.
• Updated API documentation should be clear and concise, explaining how to use the new endpoints.

Additional Context:

This feature would be particularly useful for large-scale deployments where manual management of EMH Robots would be inefficient.

┆Issue is synchronized with this Trello card by Unito

A list of the things we think we want to do, maybe not quite ready for work, but high likelihood of being worked on.

This is the staging area where specs should get fleshed out.

No limit on the list size, but we should reconsider if it gets long.

┆Issue is synchronized with this Trello card by Unito
┆Attachments: Backlog.png

Issue Description

Problem Description:

Currently, our application has tightly-coupled database logic specifically tailored for MongoDB. This makes it difficult to switch to another database or use multiple databases like Firestore without significant changes to the codebase.

Proposed Solution:

To make our application more flexible and extensible, we should implement an adapter pattern for database interactions. This way, we can more easily accommodate other databases like Firestore and even make it configurable for the end-user.

Tasks:

• Create an interface or abstract class defining the methods required for database interactions.
• Implement a MongoDB adapter following the defined interface.
• Implement a Firestore adapter following the defined interface.
• Update existing database calls in the application to use the new adapter.
• Write unit tests to ensure that both adapters work as expected.
• Update documentation to reflect the changes and how to switch between different database adapters.

Acceptance Criteria:

• The application should function as before when using the MongoDB adapter.
• The application should also work with Firestore when the Firestore adapter is used.
• Passing all unit tests for both adapters.
• Updated documentation explaining how to configure the database adapter.

Additional Context:

This refactoring aims to make our database layer more maintainable and easier to extend. It would also make it possible to use different databases for different deployments without changes to the codebase.

┆Issue is synchronized with this Trello card by Unito

This is a list of things that are good to pull off to work on, prioritized.

If there are too few items here, we should swarm against getting tasks ready for work.

┆Issue is synchronized with this Trello card by Unito
┆Attachments: To-Do.png

Cards come here after being code reviewed, and we're in a place for QA and fixing things QA finds. Design review also happens at this stage.

If we have too many cards here, we should throw a flag and figure out whether we're building things that take too many passes of QA, or if we're bottlenecked on QA time.

┆Issue is synchronized with this Trello card by Unito
┆Attachments: Verifying.png

These are the things that folks are working on.

All our engineers should have at least one item in this state.

If there are too few things here, they should be pulled off Todo.

When doing is done, cards move to Code Review.

┆Issue is synchronized with this Trello card by Unito
┆Attachments: Doing.png

This list is for items in code review.

When a task has gotten approval, it moves off to Testing.

If there are too many cards here, we should break off from other tasks to get code review done.

┆Issue is synchronized with this Trello card by Unito
┆Attachments: Code Review.png

We shipped it to production!

┆Issue is synchronized with this Trello card by Unito
┆Attachments: done.png | Done.png