chaynhq/bloom-backend

Code for the backend / API of the Bloom service

Welcome to Bloom

Currently in active development.

Bloom is a remote trauma support service from Chayn, a global charity supporting survivors of abuse across borders. Bloom is our flagship product; a free, web-based support service designed for anyone who has experienced or is currently experiencing domestic or sexual abuse. Through a combination of online video-based courses, anonymous interaction and 1:1 chat, Bloom aims to provide tailored information, guidance, everyday tools, and comforting words to cope with traumatic events. 💖

Get Involved

Do you want to make an impact with Chayn and receive special access to our organization and volunteer opportunities? Please visit our Getting Involved Guide to get started!

Other ways you can support Chayn are donating, starring this repository ⭐ (so we can find more contributors like you!), making an open-source contribution, and supporting us on social media!

Find us online:

• Website: https://www.chayn.co/
• Linktree: https://linktr.ee/chayn
• Twitter: @ChaynHQ
• Instagram: @chaynhq
• Youtube: Chayn Team
• LinkedIn: @chayn

Contributing to Bloom Backend

Before making a contribution, please read our Contributing Guidelines in the CONTRIBUTING.md file.

We ask all contributors to follow our Contributing Guidelines to help Chayn developers maintain open-source best practices.

Happy coding! ⭐

Technologies Used:

For a more detailed explanation of this project's key concepts and architecture, please visit the /docs directory.

• NestJS - NodeJs framework for building scalable and reliable server-side applications
• PostgreSQL - Object-relational SQL database system
• TypeORM - Object Relational Mapper library
• Firebase - User authentication
• Storyblok - Headless CMS for pages and courses content
• Simplybook - Appointment booking system used for therapy
• Slack - Slack webhooks to send messages to the team
• Rollbar - Error reporting
• Crisp - User messaging
• Mailchimp - Transactional email
• Docker - Containers for api and db
• Heroku - Build, deploy and operate staging and production apps
• GitHub Actions - CI pipeline

Local development

Prerequisites

• NodeJS v20.x
• Yarn v1.x
• Docker

Run in Dev Container - OPTIONAL

Recommended for Visual Studio & Visual Studio Code users.

This method will automatically install all dependencies and IDE settings in a Dev Container (Docker container) within Visual Studio Code.

Directions for running a dev container:

1. Meet the system requirements
2. Follow the installation instructions
3. Check the installation
4. After you've verified that the extension is installed and working, click on the "Remote Status" bar icon and select "Reopen in Container". From here, the option to "Re-open in Container" should pop up in notifications whenever opening this project in VS.
5. Configure your environment variables and develop as you normally would.

The dev Container is configured in the .devcontainer directory:

• docker-compose.yml file in this directory extends the docker-compose.yml in the root directory.
• devcontainer.json configures the integrations with Visual Studio Code, such as the IDE extensions and settings in the vscode directory.

See Visual Studio Code Docs: Developing Inside a Dev Container for more info.

Install dependencies

yarn

Configure Environment Variables

Create a new .env file and populate it with the variables below. Note that only the Firebase and Simplybook tokens are required. To configure the Firebase variables, first create a Firebase project in the Firebase console (Google account required). Next, follow these directions to generate a private key file in JSON format. These will generate all the required Firebase variables.

The Simplybook variables can be mocked data, meaning you do not need to use real Simplybook variables, simply copy paste the values given below. If you acquire real Simplybook environment variables, use the same format given below.

ROLLBAR_ENV=development
PORT=35001

DATABASE_URL=postgres://<username>:<password>@<host>:<port>/<db>

NODE_ENV=development

FIREBASE_TYPE=service_account

FIREBASE_PROJECT_ID=
FIREBASE_PRIVATE_KEY_ID=
FIREBASE_PRIVATE_KEY=
FIREBASE_CLIENT_EMAIL=
FIREBASE_CLIENT_ID=
FIREBASE_AUTH_URI=https://accounts.google.com/o/oauth2/auth
FIREBASE_TOKEN_URI=https://oauth2.googleapis.com/token
FIREBASE_CERT_URL=https://www.googleapis.com/oauth2/v1/certs
FIREBASE_CLIENT_CERT=

FIREBASE_API_KEY=
FIREBASE_AUTH_DOMAIN=
FIREBASE_PROJECT_ID=
FIREBASE_STORAGE_BUCKET=
FIREBASE_MESSAGING_SENDER_ID=
FIREBASE_API_ID=
FIREBASE_MEASUREMENT_ID= # must enable Google Anayltics in Firebase project

# VARIABLES REQUIRED FOR TESTING, REPLACE WITH REAL VALUES IF NEEDED
SIMPLYBOOK_CREDENTIALS='{"login":"testlogin","password":"testpassword","company":"testcompany"}'
SIMPLYBOOK_COMPANY_NAME=testcompany

# VARIABLES BELOW ARE ALL OPTIONAL
ROLLBAR_TOKEN=
ZAPIER_TOKEN=
SLACK_WEBHOOK_URL=
CRISP_TOKEN=
CRISP_WEBSITE_TOKEN=
MAILCHIMP_API_KEY=
MAILCHIMP_AUDIENCE_ID=
MAILCHIMP_SERVER_PREFIX=
RESPOND_IO_CREATE_CONTACT_WEBHOOK=
RESPOND_IO_DELETE_CONTACT_WEBHOOK=

Run the App Locally

Using Docker - RECOMMENDED

The project is containerized and can be run solely in docker - both the PostgreSQL database and NestJS app. To run the backend locally, make sure your system has Docker installed - you may need Docker Desktop if using a Mac or Windows.

First make sure the docker app is running (just open the app). Then run

docker-compose up

You should see this in the shell output:

Listening on localhost:35001, CTRL+C to stop

Note: you can use an application like Postman to test the apis locally

Without Docker

First install postgres. Next follow directions to seed the database, then run:

yarn start:dev

You should see this in the shell output:

Listening on localhost:35001, CTRL+C to stop

Database migrations

A migration in TypeORM is a single file with SQL queries to update a database schema as updates/additions are made. Read more about migrations here.

Migrations are automatically run when the app is built docker (locally) or Heroku for staging and production apps.

You'll need to generate and run a migration each time you add or update a database field or table.

To generate a new migration

yarn migration:generate

Add the new migration import into typeorm.config.ts

To run (apply) migrations

yarn migration:run

To revert a migration

yarn migration:revert

Note that when running the app in Docker, you may need to run migration commands from the docker terminal/Exec

New environment variables must be added to Heroku before release.

Run unit tests

To run all unit tests

yarn test

To have your unit tests running in the background as you change code:

yarn test:watch

Formatting and linting

To run linting

yarn lint

To lint and fix

yarn lint:fix

Formatting and linting is provided by ESLint and Prettier (see the relevant configs for details).

Workspace settings for VSCode are included for consistent linting and formatting.

Seed Local Database

If you're an open-source contributor, add data to your local database by seeding it with a backup file. Please read the Chayn Tech Wiki Guide to obtain a backup file and follow directions to seed the local database.

If you're staff and have access to Heroku, you also have the option to seed the database via the following script. Before you start, make sure:

1. bloom-local-db container is running in Docker
2. you are logged into the Heroku via your terminal. Read more about the Heroku Cli here
3. Replace <HEROKU_APP_NAME> with the correct Heroku app name in the seed-local-db.sh file
4. Run chmod +x ./seed-local-db.sh in your terminal to make the file executable

After the above has been confirmed, run

bash seed-local-db.sh

Git Flow and Deployment

The develop branch is our source of truth, not main.

Create new branches from the develop base branch. There is no need to run the build command before pushing changes to GitHub, simply push and create a pull request for the new branch. GitHub Actions will run build and linting tasks automatically. Rebase and merge feature/bug branches into develop.

This will trigger an automatic deployment to the staging app by Heroku.

When changes have been tested in staging, merge develop into main. This will trigger an automatic deployment to the production app by Heroku.

Swagger

Swagger automatically reflects all of the endpoints in the app, showing their urls and example request and response objects.

To access Swagger simply run the project and visit http://localhost:35001/swagger

License

Bloom and all of Chayn's projects are open source. The core tech stack included here is open source however some external integrations used in the project require subscriptions.

bloom-backend's Issues

Bump @nestjs/core from 8.0.11 to 9.0.5

Overview
Dependabot PRs are automatically created. Our cypress tests don't currently run against code on the branch so we need to run them manually for now. An automated way of doing this is in the pipeline. However, for now we need to run the tests manually

Action Items

• Clone the branch raised by dependabot to your local computer
• Run up both bloom-backend and bloom-frontend to ensure that this change in dependency has not affected the site
• Run backend unit tests to ensure they're all passing
• Run frontend cypress tests to ensure they're all passing
• Commit any changes to the dependabot branch and push up
• Comment on the ticket that this change has been verified and request reviews from the team (@kyleecodes)

chore(deps): bump newrelic/deployment-marker-action from 2.2.0 to 2.5.0

Dependabot opened a pull request to update a dependency. Please review it: #456

• Comment on this issue tagging Chayn staff (@kyleecodes) to be assigned this issue.
• Follow directions in the Chayn Dependency Upgrade Guide here: https://chayn.notion.site/Chayn-Tech-Contributor-Wiki-5356c7118c134863a2e092e9df6cbc34?pvs=4

Create accurate error code for users who are applying a code twice to their account

Overview

We want to provide a more accurate error message for users who try and apply a code to their account twice. To do this, we need a better error message than ALREADY_IN_USE. We want a new error code ALREADY_APPLIED

Action Items

• Pull develop branch to ensure your repo is up to date
• Create your own branch
• See resource and tips below before starting.
• Create the change to service methods.
• Add a new service test to test the scenario where a user is applying a code again.
• Create PR and tag @eleanorreem to the PR

Resources/Instructions

• The endpoint users hit is POST /partner-access/assign see /bloom-backend/src/partner-access/partner-access.controller.ts.
• The endpoint uses the assignPartnerAccess service method which checks the validity of the code with the getValidPartnerAccessCode service method.
• Initial suggestion is to pass an optional userId into getValidPartnerAccessCode. You can then compare the users userId with the access codes userId.
• Please note this is a suggestion after having a quick look at the code and might not be the best way. Feel free to improve the implementation

Delete the POST /user/me endpoint

Overview

This ticket involved removing an outdated POST /user/me endpoint. This issue was blocked by a frontend issue. The frontend needs to be migrated over to the new GET /user/me endpoint before this endpoint is deleted.

Action Items

• Remove the POST /user/me endpoint from the user.controller.ts
• Run unit tests to ensure everything is still working as expected.
• Run Cypress tests to ensure everything is still working as expected

GitHub Actions: implement automation for unassigning abandoned issues

Overview

Implement a GitHub Action that automatically unassigns contributors from an issue after days of inactivity.
Starting out, we will do 3 months of inactivity, but will adjust as needed.

Action Items

• Draft a helpful message tagging the assignee.
• Design plan for the GitHub Action, document in internal docs.
• Write a new workflow and submit a PR.

Resources

https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
https://docs.github.com/en/actions/managing-issues-and-pull-requests/using-github-actions-for-project-management
https://github.com/marketplace/actions/unassign-contributor-after-days-of-inactivity
https://github.com/actions/stale
https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows

Bump @nestjs/testing from 10.3.7 to 10.3.8

Dependabot opened a pull request to update a dependency. Please review it: #431

• Comment on this issue tagging Chayn staff (@kyleecodes) to be assigned this issue.
• Follow directions in the Chayn Dependency Upgrade Guide here: https://chayn.notion.site/Chayn-Tech-Contributor-Wiki-5356c7118c134863a2e092e9df6cbc34?pvs=4

Create endpoint to get and update Partner admins

Overview

We need to restrict access to users who are no longer partner admins. However, we want to keep the history of whether a user is a partner admin. We have created an active column in the partner admin table.

In bloom-frontend there is a Super Admin dashboard on /admin/dashboard. This feature will loosely follow the pattern of the UpdateTherapyAdminForm in Bloom-frontend.

What our new admin form will need is:

• Access to the GET /user point. The Get user endpoint query will need to be able to include the partner admin table and filter by whether the partner admin row exists or not. i.e. you would get a searchQuery which might have
  { "relations": ["partner-admin"], "partnerAdmin": { "partnerAdminId": "IS NOT NULL"} }
  Note that this endpoint should now optionally return a users partnerAdmin data.
• A PATCH endpoint /partner-admin/:id which takes a body with the updates to make. Please ensure this is behind Super Admin Authentication. In this case the body will be
  { "active": Boolean }

These changes should unblock this issue on Bloom-frontend.

Action Items

• Take a look at the implentation of GET /user and PATCH /partner-access/:id. You will be following the implementations of these endpoints
• Make the changes listed above to the GET /user endpoint and service methods and write adequate service tests and optional controller test
• Create a PATCH /partner-admin/:id endpoint and with service method. This should be super admin authenticated that takes the body stated above. Ensure the appropriate DTO is created as well.
• Commit and Push to your branch
• Tag @eleanorreem in your PR

Enable Users to update their email

Overview

Currently our PATCH /user endpoint only allows the user to update their name. We want the user to be able to update their email as well.

Action Items

• Take a look at the PATCH /user endpoint in /bloom-backend/src/user/user.controller.ts
• Update the UpdateUserDTO to contain a email property. This should not be required.
• If a user decides to update their email, this will need to be changed in Firebase as well as in our database. Therefore the updateUser service method needs to handle this. If the user supplies a new email in the DTO, the method should first update the email in Firebase and then when that passes, it should update the user in the database. If the user email update fails, it should throw with the appropriate errors such as the ones in the createUser method.
• Create a service test to safeguard updating an email. There should be a pass and fail scenario.

Resources

• Firebase admin api

Refactor use of getUserDto schema between functions

Is your feature request related to a problem?

Most of our backend api requests are related to users, so before the request function is run, we get the current user from the database and make the user data available in the request and following functions. The problem is that we are passing around the user data in a serialized schema GetUserDto and instead we should be using the pure UserEntity schema/types, for all internal functions. GetUserDto schema should only be used to serialize user data before returning the response, i.e. in the controller

Describe a solution:

• Remove user from the request context - we are aiming to use userEntity instead - see FirebaseAuthGuard.tsx and getUserByFirebaseId function in user.service.ts
• Replace all uses of req['user'] in controllers, instead using req['userEntity']
• Remove all uses of GetUserDto from our functions/service files, instead using UserEntity type
• Fix any related issues - running yarn test and yarn lint will help discover issues
• You should also run Cypess tests to ensure this doesn't break anything in the frontend.
• This is a large issue so you may want to break down into smaller issues

This is the first step (see #454) in improving the maintainability and performance of the API and how it handles users. The cleaner typing will help future contributors understand the code!

Additional context and resources:

Tests may need to be fixed following this update - run to check failing tests

Ticket breakdown

#547
#546
#545

GH Flow: new descriptive issue labels

Overview

Duplicate of this issue - chaynHQ/bloom-frontend#701

Action Items

Resources

Add development container to Bloom-backend

Overview

A development container allows you to use a container as a full-featured development environment. They are an efficient option for contributors to get started. It would be great to provide this as a quick start up option for our community.

Action Items

• Read and follow instructions in this guide
• Create the dev container and write documentation in ReadME.md in a section under local development
• Ensure the dev container works as expected
• Make a PR and tag @kyleecodes or @eleanorreem . They will ensure that the container works on their device

Resources/Instructions

• https://code.visualstudio.com/docs/devcontainers/create-dev-container
• https://containers.dev/#:~:text=It%20can%20be%20used%20to,of%20supporting%20tools%20and%20editors.

Create new PATCH partner endpoint

Overview

We want to at some point be using Rest properly. Currently, this is not the case. Each endpoint which deviates from REST patterns should be duplicated and corrected. We can later migrate the frontend over to the correct endpoint and delete the incorrect usage. We don't need to be super strict but just better than where we are now.

Our current url POST /v1/partner/delete does not make sense. Firstly, this is because functionally it is a soft delete. We merely set the status of the partner from active to inactive. Secondly the usage of POST is incorrect.

Action Items

• See /bloom-backend/src/partner/partner.controller.ts. Look for the POST /v1/partner/delete endpoint. We want to replicate the functionality of this endpoint.
• We want this url to be a PATCH request with the url /v1/partner/:id and with a body that accepts {active: boolean} .
• You will also need to create a new service method with a different name. Instead of deletePartner, it should be updatePartner. updatePartner should take both the partnerId and a body DTO which all the changes inside. Please see bloom-backend/src/partner-feature/partner-feature.service.ts. Look at updatePartnerFeature as an example.
• Please feel free to delete the old version.
• Create a test file with a new test for the new service method. It would be good to cover the pass and fail scenario.

Resources/Instructions

• the bloom-backend/src/partner-feature/partner-feature.service.ts folder is a better example of how we want our controllers and services to be structured. Take a look at those so you have an understanding of our preferred patterns.

Bump jose from 2.0.5 to 2.0.6

Dependabot has already raised a PR for this.

Please also read through this part of the volunteer wiki to get more information on how to complete dependency upgrade issues.

Approach

• Clone the branch raised by dependabot to your local computer
• Run up bloom-backend to ensure that this change in dependency has not affected the site
• Run tests to ensure they're all passing
• Commit any changes to the branch and push up
• Comment on the ticket that this change has been verified and request reviews from the team (@swetha-charles or @eleanorreem)

Create CONTRIBUTING.MD file

Overview

We need to create a CONTRIBUTING.md file to guide developers contributing to Bloom.
Additionally this helps fulfill Community Standards for this repo.

Action Items

• Check out resources below as a guide.
• Contribute to Bloom to learn project-specific requirements.
• Draft CONTRIBUTING.md and open a PR.

Resources

• Official GitHub contributing guidelines guide
• Example CONTRIBUTING.md file by GitHub
• Example CONTRIBUTING.md file by Ruby for Good

Tests for Partner.createPartner

Overview

Our partner service is currently untested. This is not great. Ideally we would have at least one pass and fail scenario for each endpoint.

Action Items

• You might need to create a new test file if it has not already been created
• Create a test scenario where partnerService.createPartner passes
• Create a test scenario where partnerService.createPartner fails

Resources

See other service tests such as bloom-backend/src/partner-feature/partner-feature.service.spec.ts to see how tests can be structured.

Add link to CONTRIBUTING.md file in README.md

Overview

We need to link to the CONTRIBUTING.md file in the README.md so contributors can more easily see the contributing guidelines.

Action Items

• Under the title in Bloom Backend section in the README.md, above "Technologies Used", add the following:
  "To make a contribution, please read our Contributing Guidelines in CONTRIBUTING.md"
• Make sure the sentence above contains a Markdown link to the repo's CONTRIBUTING.md file.

Resources/Instructions

• How to Create Markdown Links

Bump rimraf from 5.0.5 to 5.0.7

Dependabot opened a pull request to update a dependency. Please review it: #432

• Comment on this issue tagging Chayn staff (@kyleecodes) to be assigned this issue.
• Follow directions in the Chayn Dependency Upgrade Guide here: https://chayn.notion.site/Chayn-Tech-Contributor-Wiki-5356c7118c134863a2e092e9df6cbc34?pvs=4

Ensure Partner Admin Authguard is checking whether the admin is active

Overview

We want to toggle the state of a Partner admin to active or inactive. This means we need an added check in our auth guards to ensure we are not allowing inactive partner admins to still make changes.

This change is blocked by this PR

Action Items

• Create branch
• Have a look at the partner admin auth guard bloom-backend/src/partner-admin/partner-admin-auth.guard.ts and ensure where appropriate that you are retrieving and checking for partner admin active status. This Authguard should error with a 403 if the partner admin is no longer active.
• Create tests for auth guard. 1 test should have the partner admin as active and another should have the partner admin as inactive.
• Commit and Create PR
• Tag @eleanorreem and @kyleecodes in your PR and one of us will get back to you soon!

Add security policy

Overview

Create a security policy to guide contributors through reporting a security vulnerability on Bloom.
Additionally this helps fulfill Community Standards for this repo.

Action Items

• Use GitHub's click-through process for maintainers to easily add universal security policies to their repos, found in this repos security tab.
• Then copy paste Chayn's security policy from YSM.

Resources/Instructions

• Official GitHub Docs - Adding a security policy to your repository

Create user shouldn't fail when Crisp API request fails

Overview

Currently when a user account is created, we add a crisp profile for the user. If this request to crisp fails, we propagate the error back to the user and it looks like the account creation failed. Instead of propagating the error back, we want to just highlight the error in Rollbar and send the users back a 200.

Action Items

• The best way to get this to work in action is to run bloom-frontend. In the backend, remove the CRISP api token from your backend env variables. If you try and create the user through the UI, you should be propagated back an error.
• Look at /bloom-backend/src/user/user.service.ts. The createUser method is used to create users. You can see that a Crisp API request failure would cause the endpoint to error.
• Update the createUser method so that once the user is successfully created without error, we then create a Crisp Profile. If the crisp profile fails, we get a Rollbar error and the createUser method returns successfully with the formatted user object. The Crisp API request should not throw when it fails.
• Create a service test that covers CRISP api failure in the createUser method.

Configure issue templates

Overview

We need to create issues templates to guide contributors through creating issues on Bloom
Additionally this helps fulfill Community Standards for this repo.

Action Items

• Use example issue templates from YSM as a template.
• Configure issue templates on this repo (start with Blank, Feature Request, and Bug Report)

Resources

• Official GitHub Docs - Configuring issue templates for your repository

chore(deps): bump github/codeql-action from 2 to 3

Dependabot opened a pull request to update a dependency. Please review it: #457

• Comment on this issue tagging Chayn staff (@kyleecodes) to be assigned this issue.
• Follow directions in the Chayn Dependency Upgrade Guide here: https://chayn.notion.site/Chayn-Tech-Contributor-Wiki-5356c7118c134863a2e092e9df6cbc34?pvs=4

Upgrade node to node 16+

Background
Github actions will no longer support node 12 soon. We are trying to upgrade all our applications to node 16 or higher.

Task

• upgrade node 16 to a higher a version as possible without affecting other packages. This might not be possible. There might be some packages that aren't compatible with node 16+ so you will need to upgrade them too.
• check all the happy paths work

Create Session Feedback Service and Controller and POST endpoint

Overview

We want to start collecting feedback about our courses so we know where to improve. This ticket covers creating the controller and service for the session-feedback service and a single endpoint for creating a session-feedback entity. This is currently blocked by this issue

Action Items

• Create a branch from develop
• Take a look at a simple controller and service for an entity such as the feature entity. See /src/feature. You can use these as a model for the files you need to create.

The specific files you will need to create are:

• a file for the session-feedback dto
• controller
• interface
• module
• repository
• service

For creating a post endpoint

• Create a post endpoint in the controller. The body of the request should be a session-feedback dto. It should also return a session-feedback dto. Ensure you validate the body in the request. This request also needs to be behind firebase auth guard (see other endpoints such as POST session-user as an example).
• You will need a createSessionFeedback service method. Checks the session Id exists and throws if the session doesn't exist. It should store the new session feedback in the database and return the new session-feedback dto.
• Create a test for the session feedback service to cover success and error states.
• Commit , push and create a PR tagging @eleanorreem

Update backend continuous intergration to match bloom-frontend

Background
We recently updated the bloom-frontend integration flow in github actions. It has worked really well for us and we want the same steps to happen in the backend.

Task

• have a look at the integration steps in bloom-frontend .github/workflows file (ignore the manual-deploy workflows as they are not currently working)
• the workflows might not exactly match but get them as close as you can (e.g. there is no cypress in the backend etc)
• Please ask any questions to @swetha-charles or @eleanorreem if you have any issues

Bump terser from 5.9.0 to 5.14.2

Dependabot has already raised a PR for this.

Please also read through this part of the volunteer wiki to get more information on how to complete dependency upgrade issues.

Approach

• Clone the branch raised by dependabot to your local computer
• Run up bloom-backend to ensure that this change in dependency has not affected the site
• Run tests to ensure they're all passing
• Commit any changes to the branch and push up
• Comment on the ticket that this change has been verified and request reviews from the team (@swetha-charles or @eleanorreem)

Configure PR templates

Overview

We need to create PR templates to guide contributors through submitting pull requests on Bloom.
Additionally this helps fulfill Community Standards for this repo.

Action Items

• Research project-specific requirements before opening a PR on Bloom.
• Configure pull request templates.

Resources

• Official GitHub Docs - Creating a pull request template for your repository
• Example PR templates

Add upto date database schema image to docs /data-architecture.md

Overview

We need to update our database architectural docs.

Action Items

• Create a new section called Database Schema and add the following image:

• Replace the current Database model diagram and replace with this image:

Write tests for the partner access service

Background
We want to have a more robust code base. When bloom was developed it was not thoroughly tested and we are trying to fill in the gaps.

Task

• write tests for /src/partner-access/partner-access.service.spec.ts.
• the file has already been created and a couple of tests have been started in src/partner-access/partner-access.service.spec.ts
• if you see logic in the code that doesn't make sense or can be improved, let @swetha-charles or @eleanorreem know as it is possible that the logic is wrong and create a bug report.

Possible test scenarios

• a partnerAdmin fails to create a partner access code as the partner doesn't exist
• a user cannot assign an access code to their account as the user doesn't exist
• a user cannot assign an access code to their account as the partner doesn't exist
• a user successfully assigns partner access codes on sign up
• a user fails to assign partner access code on sign up

Bump supertest from 6.3.4 to 7.0.0

Dependabot opened a pull request to update a dependency. Please review it: #435

• Comment on this issue tagging Chayn staff (@kyleecodes) to be assigned this issue.
• Follow directions in the Chayn Dependency Upgrade Guide here: https://chayn.notion.site/Chayn-Tech-Contributor-Wiki-5356c7118c134863a2e092e9df6cbc34?pvs=4

Create GET /subscription_user endpoint

Overview

We want to start breaking up the GET /user/me request and only fetch information on the pages it is needed. This is starting with subscriptions. We also are misusing types across the site so we want to improve the ways of transferring data. Note that we don't want any DTOs to be used in the service, only in the controllers. We are also phasing out all ITypes such as ISubscriptionUser. All formatting needs to happen in the controller. I have labelled this ticket as advanced, not because of the complexity, but because of the confidence needed in controller/service interactions and appropriate types.

Action Items

• get familiar with Nestjs best practices with the resources below
• Create a service method that return an array of SubscriptionEntities for a user. Please note, you will want to be returning the subscription name i.e. whatsapp, not just the subscription_user table. this might look like SubscriptionUserService.getSubscriptions(userId)
• Create a GetSubscriptionUsersDto which returns an array of GetSubscriptionUserDto (you might want to make 2 dtos, one that returns an array of the other)
• The GetSubscriptionUserDto needs to have the following properties:
• ```
  {
  id: string;
  subscriptionId: string;
  subscriptionName: string;
  subscriptionInfo: string;
  createdAt: Date;
  cancelledAt: Date | null;
  }

- [ ] Create a GET /subscription_user endpoint that returns all the subscriptions of the authenticated user. It should return a GetSubscriptionUsersDto. Please use NestJs recommended guidance to build the DTO rather than using the pattern that is in use on the site as it is incorrect. Formatting the return DTO needs to happen in the controller  


### Resources
- https://docs.nestjs.com/openapi/types-and-parameters
- https://docs.nestjs.com/openapi/mapped-types
- https://medium.com/ayuth/proper-way-to-create-response-dto-in-nest-js-2d58b9e42bf9

Create new GET /user/me endpoint

Overview

We want to at some point be using Rest properly. Currently, this is not the case. Each endpoint which deviates from REST patterns should be duplicated and corrected. We can later migrate the frontend over to the correct endpoint and delete the incorrect usage. We don't need to be super strict but just better than where we are now.

Action Items

• See bloom-backend/src/user/user.controller.ts. Look for the /v1/user/me endpoint
• Duplicate the endpoint but as a GET request. Do not delete the old version. The functionality should be the same.
• Write some comments to explain the transition and which endpoint should be used and which is going to be archived

Move README.md documentation to new /docs directory

Overview

We should simplify our README by separating the key concepts and architecture guides into their own separate /docs directory, similar to how Soulmedicine is organized, and turn the README into a brief overview of the project and quick start guide.

Action Items

• Create a /docs folder in the root directory.
• Move the Key Concepts section of the README.md into the /docs folder in a file called key-concepts.md
• Move the Database Models section of the README.md into the /docs folder in a file called data-architecture.md
• Write the following sentence under the "Local Development" section title in the README.md:
  "For a more detailed explanation of this project's key concepts and architecture, please visit the /docs directory."
• Make sure the above sentence contains a Markdown link to the /docs directory, which would be: https://github.com/chaynHQ/bloom-backend/tree/develop/docs (This is where a README.md file will be located in the near future.)

Resources:

• How to make Markdown Links

Pass partnerAdmin.active property

Overview

We are trying to implement a feature in the frontend which allows us to check whether a partner admin is active or not. However, the partnerAdmin.active property is not being passed to the front end by the backend. Please see frontend issue . The user data is fetched via the GET /user/me endpoint. This endpoint needs to return the partnerAdmin.active property.

Action Items

• update the interface to include active at src/partner-admin/partner-admin.interface.ts
• update the user payload formatter to include the active property on the appended partnerAdmin at src/utils/serialize.ts
• Manually test the GET /user/me endpoint to ensure everything is working as expected
• Run tests and linting to ensure everything is passing.

Bump moment from 2.29.1 to 2.29.4

Dependabot has already raised a PR for this.

Please also read through this part of the volunteer wiki to get more information on how to complete dependency upgrade issues.

Approach

• Clone the branch raised by dependabot to your local computer
• Run up bloom-backend to ensure that this change in dependency has not affected the site
• Run tests to ensure they're all passing
• Commit any changes to the branch and push up
• Comment on the ticket that this change has been verified and request reviews from the team (@swetha-charles or @eleanorreem)

Bump ts-jest from 29.1.2 to 29.1.3

Dependabot opened a pull request to update a dependency. Please review it: #433

• Comment on this issue tagging Chayn staff (@kyleecodes) to be assigned this issue.
• Follow directions in the Chayn Dependency Upgrade Guide here: https://chayn.notion.site/Chayn-Tech-Contributor-Wiki-5356c7118c134863a2e092e9df6cbc34?pvs=4

Add Active column to Partner Admin Column

Overview

We want to toggle the permissions of a Partner Admins but maintain the history of a user. For now we want to do this by adding a column "active" with a boolean type to the partner admin table. The column is required (i.e. cant be null) and the default is set to true.

Action Items

• Create a branch
• Update the entity in /bloom-backend/src/entities/partner-admin.entity.ts
• Run the migration script yarn migration:generate
• Check that the migration makes sense
• Run the migration script yarn migration:run
• Check you see what is expected in your database
• Run tests
• Commit and make PR
• Tag @eleanorreem and @kyleecodes in the PR

Resources

• see Typeorm documentation for help with writing migration

Refactor user fetching to remove unnessary joins

Blocked by #453

Is your feature request related to a problem?

Most of our backend api requests are related to users, so before the request function is run, we get the current user from the database and make the user data available in the request and following functions. The problem is that for each request, we are calling the user data with joins to all relationships, whilst the related data is not usually required for the current request. E.g. the api request for a user starting a session, does not require the createSessionUser to have access to user.partnerAccess or user.therapySession relationship data, but it is still being requested.

Describe a solution:

• Remove the joins in getUserByFirebaseId function in user.service.ts so that the userEntity request context only includes the user data with no joins/relations.
• Ensure no functions are now broken, i.e. any functions that did use the relationships will no longer have access to the required data. Look for functions that use this data by searching for req['userEntity']. I couldnt see any uses of user.relationships but should be double checked.

This change will massively improve the performance of the API and the code complexity and maintainability in future!

Create a session feedback table

Overview

We want to create a feedback mechanism for our course sessions. We need to create a new model to store this feedback in.

Action Items

• Create a branch
• Ensure your local database is up to date and you have the application running locally.
• Create a new entity in /src/entities called session-feedback. This entity will have 3 columns:

sessionFeedbackId	sessionId	feedbackTags	feedbackDescription
string	string (note that it should have a many (session-feedback.sessionId) to one (session.session Id) relationship )	Enum Array (see enum array example below)	string

enum FeedbackTags {
      RELATABLE = "relatable",
      USEFUL = "useful"
      INSPIRING = "inspiring",
      TOO_LONG = "too long",
      TOO_COMPLICATED = "too complicated"
      NOT_USEFUL = "not useful"
}

• Following the instructions on the ReadMe to create a migration
• Commit and push your changes and tag @eleanorreem

Resources

• typeorm enum column types
• Type ORM documentation on migrations
• Stack overflow on enum array column types

Fix Typo in Contributing File

Overview

For new to open-source volunteers - the word "sustainable" in the Contributing Docs under the Issue Limit Policies header is misspelled and needs corrected. This issue is best for contributors new to open-source because it does not require local development. However we recommend contributors still clone the repo locally and follow all the steps in the Contributing file.

Action Items

• Read and follow the directions in the Contributing file.
• Correct the typo: sustainble -> sustainable.
• Open a pull request.

GitHub Action: implement automation for welcoming new contributors

Overview

Implement a GitHub Action that will automatically welcome new contributors in PRs.

Action Items

• Draft an informative message linking contributors to helpful information.
• Ensure that the action will not greet dependabot or any automated PRs.
• Write a new workflow and submit a PR.
• Document in internal docs.

Resources

https://github.com/marketplace/actions/auto-message-for-pr-s-and-issues
https://github.com/actions/first-interaction
https://github.com/marketplace/actions/first-interaction
https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment

Create endpoint to update user PATCH v1/user

Overview

We currently don't have an endpoint to update a user. We need one to do the next iteration of the user profile where the user can update their subscription preferences. This ticket is just to create the endpoint and service method. We can then have the option of updating a users name and contact permissions. Note that the email update is more complicated and will come at a later point.

This endpoint will only allow the user that is authenticated to update their own data.

Action Items

• create endpoint in the bloom-backend/src/user/user.controller.ts with a body that can update the authenticated user. This endpoint should be a PATCH endpoint. The body for now should only contain these optional values: { name: string, contactPermission: boolean, serviceEmailsPermission: boolean}
• The endpoint should have the firebaseAuthguard attached.
• See endpoints like GET /user/me for examples about how to extract the user from the authguard.
• create method in userService that will update the user columns.
• write service tests with a pass and fail scenario.

Enable Users to be filtered by whether they are a Partner admin

Overview

We want to be able to filter users by whether they are a partner admin or not. Our current implementation of GET users only allows us to filter by partnerAdminId. It does not allow you to check whether partnerAdminId is null or not. We came across this issue in this frontend issue. . In this ticket we want to enable the frontend to be able to get all partnerAdmin users (active and inactive). The way to enable this is to let the user filter partnerAdminId by "IS NOT NULL".

Action Items

• Read through the frontend issue so you understand the context.
• The searchQuery param will need to take a URI encoded object which looks like this:

 {
    "email": "[email protected]",
    "partnerAdmin": {"partnerAdminId": "IS NOT NULL"},
    "relations": ["partnerAdmin"]
}

• Enable the service method getUsers to filter the users by whether the partnerAdminId is null or not. See some suggestions about how to do this in this stack overflow question

Docs: Git Flow Update

Overview

Bloom's frontend deployments were updated from from Heroku to Vercel.
We determined new standards for keeping out git flow organized: (chaynHQ/bloom-frontend#720).

1. develop is staying our default branch
2. maintainers must only merge commits from develop to main, never squash or rebase, to keep the main's git history identical to develop.

These recent changes need updated in several areas of Bloom's docs:

Action Items

• Update README. NOTE: More deployment updates are anticipated, so keeping this a minor change for now.
• Update internal maintainer docs.
• Update CONTRIBUTING.md file.

Resources/Instructions

Refactor getUserByFirebaseId subscriptions

Overview

We want to start breaking up the GET /user/me request and only fetch information on the pages it is needed. This is starting with subscriptions. We created a new endpoint in this ticket to have a bespoke endpoint for getting subscriptions . The frontend migration is in this ticket and blocks this refactor. After the frontend has been migrated over, we can start breaking up the GetUserDto and remove subscriptions from the object.

Action Items

• Remove leftJoins of subscription and subscription_user table from the database query in userService.getUserByFirebaseId.
• This will impact the firebase module and therefore the rest of the site. There may be significant refactors ahead.
• You will need to remove subscription_user and subscription imports from most modules as they will no longer be required.
• Remove all instances of ISubscriptionUser. It should either be an entity or a dto.
• Remove subscriptions property from the GetUserDto.

Link to our Volunteer Info page in our README.md

Overview

Currently, our README links interested volunteers directly to the volunteer form, not to our volunteer info page (which contains the form). We need the README to link to the Getting Involved volunteer info page instead, similar to how our CONTRIBUTING.md file does.

Action Items

• Replace the text in the README.md under the Getting Involved section:
  If you would like to help Bloom and receive special access to our organization and volunteer opportunities, please get in touch with us to express your interest in volunteering via this form."
  with the following text:
  "If you would like to help Chayn and receive special access to our organization and volunteer opportunities, please visit our Getting Involved page."
• Make sure the above sentence contains a markdown link to our Getting Involved page: https://www.notion.so/chayn/Get-involved-423c067536f3426a88005de68f0cab19?pvs=4

Resources/Instructions

• How to make Markdown Links

Bump follow-redirects from 1.14.4 to 1.15.1

Dependabot has already raised a PR for this.

Please also read through this part of the volunteer wiki to get more information on how to complete dependency upgrade issues.

Approach

• Clone the branch raised by dependabot to your local computer
• Run up bloom-backend to ensure that this change in dependency has not affected the site
• Run tests to ensure they're all passing
• Commit any changes to the branch and push up
• Comment on the ticket that this change has been verified and request reviews from the team (@swetha-charles or @eleanorreem)

Bump newrelic from 11.15.0 to 11.17.0

Dependabot opened a pull request to update a dependency. Please review it: #434

• Comment on this issue tagging Chayn staff (@kyleecodes) to be assigned this issue.
• Follow directions in the Chayn Dependency Upgrade Guide here: https://chayn.notion.site/Chayn-Tech-Contributor-Wiki-5356c7118c134863a2e092e9df6cbc34?pvs=4

Node: Upgrade Node to 20

Overview

We should upgrade to Node 20. Node 17 is no longer supported, Node 18 is required to fully leverage NextJS, and Bloom's frontend is already on Node 20. This will be necessary if Bloom's frontend and backend repos ever combine into a single repo.

Action Items

• Upgrade Node to 20 in package.json
• Run tests and document any errors that must be fixed. If there are many or highly complex errors, we will open new issues for them.
• Fix any issues that may arise.
• Specify node version in GitHub Actions in /workflows directory.
• Specify node version in README documentation.

Resources/Instructions

• NodeJS Blog: Node.js 18 is now available!
• How to Upgrade Node and NVM Locally

Add informative logging when partner access assignment fails on sign up

Currently when a user signs up with an access code and it fails, we get the error in the rollbar logs saying "DOES_NOT_EXIST". Ideally we would have more granular logs with more information. This error is thrown in src/partner-access/partner-access.service.ts

Additional useful information could be

• email of user
• access code used