MNTOR-1800: unsubscribe from free monthly report

[mansaj]

References:

Jira: MNTOR-3582

Description

1. Util function for table subscriber_email_preferences
   The util funcs take care of the fetches and updates of email preferences. It gets the stored settings from 2 tables and consolidate them. Follow up work will be tracked in MNTOR-3557

2. Util function to generate unsubscribe URL

3. API endpoint to verify unsub url and unsub the user from monthly monitor reports

Screenshot (if applicable)

Not applicable.

How to test

• get the output of console.info(generateUnsubscribeLink(session?.user.email || "")); on any page
• visit that link
  • if the pref table is empty, a row will be created
  • if the pref table record already exists, it will check for the value of monthly_monitor_report_free value and change it to false if not

Checklist (Definition of Done)

• Commits in this PR are minimal and have descriptive commit messages.
• I've added or updated the relevant sections in readme and/or code comments
• Product Owner accepted the User Story (demo of functionality completed) or waived the privilege.
• All acceptance criteria are met.
• Jira ticket has been updated (if needed) to match changes made during the development process.
• Jira ticket has been updated (if needed) with suggestions for QA when this PR is deployed to stage.

[github-actions]

Preview URL 🚀 : https://blurts-server-pr-4988-mgjlpikfea-uk.a.run.app

[mansaj]

lgtm and wfm locally... I was going to say subscriber_email_preferences.primary_email should have a FK constraint on email_addresses or subscriber.primary_email, but I guess that we want to keep a record permanently of the email address that the user opted out of?

What happens if a user changes their primary email address, will they start getting these emails again?

Yea I thought about that too. I think it might be simpler to not have this dup field and just always do join... but it's going to be annoying since we need to request with email as a param often... and it's going to take a performance hit

We can also create a VIEW with these two tables.. that's probably what we should've done with subscribers and email_addresses also..

[mansaj]

@rhelmer got rid of primary_email in the new table to avoid syncing
9469811

[github-actions]

Cleanup completed - database 'blurts-server-pr-4988' destroyed, cloud run service 'blurts-server-pr-4988' destroyed