feat: send email when preexisting user has been assigned to task

[eensander]

This PR (re)introduces MailTrap to send emails to users that already have an account and are assigned to a new task.

Please notice:

• This PR requires defining the MAILTRAP_TOKEN in the .env file (see .env.example),
• Introducing this PR, emails are sent through two different channels: all emails regarding authentication are sent through Supabase and MailTrap. The difference occurs when locally developing: all regular authentication emails will be tampered by InBucket hosted by the local Supabase setup. However, even when using the local setup, emails sent to assigned existing users will be sent through the live MailTrap instance. Please be aware of this fact when testing, that for this specific action you might have to use your real email-address to validate it is working, or check the MailTrap logs.

To test:

1. Create new project
2. Add documents to project
3. Create task in project
4. Assign a new user email to the task
5. -> Validate in local InBucket that the targeted user received the "Invited to join Lawnotation" email
6. Create new task in project
7. Assign same user email as before to this task
8. -> Validate in MailTrap logs, or your live inbox if you used your real email-address, that the "Assigned to new task" email has been delivered.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
lawnotation	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 2, 2024 0:19am

[CvdL-UM]

Discussion points:

• Is it possible to recycle one of Supabase's email template end points instead of using Mailtrap?
• Adding a settings panel where people can decide whether to receive new assignment emails or not

[eensander]

@CvdL-UM,

First, I implemented your suggested change. Next, considering your points:

1. Although that would definitely keep the code more concise, and require less changes, I am not sure of the implications if we would recycle an existing supabase template for sending assignments-emails. The reason being that these emails are sent as a result of an authentication action, and therefore sending the assignment email would probably imply a side-effect to occur.
   • The available templates are: Confirm Signup, Invite User, Magic Link, Change Email Address, Reset Password. As far as I know, only Invite User and Magic Link are currently used. Maybe we want to use Change Email Address in the future so I leave it out aswell. That leaves Confirm Signup and Reset Password as options.
   • I suspect that the Confirm Signup template requires the user to not exist yet, which would disqualify it as an option,
   • The template Reset Password is left, but we'd have to investigate if it doesn't provide unwanted side-effects,
   • We are restricted to using the available variables in the templates. Passing an URL to the newly assigned task_id would require setting it in the metadata, for example. Not impossible, but maybe a little hacky.
   • Concluding: this point would require additional research. So the question for now is: what is the urgency of sending emails for assignments to existing users at the moment?
2. I definitely think this would be a great addition. We have to discuss building a settings page where users can manage such preferences.

[eensander]

Regarding the topic of integrating a custom method for sending emails in conjunction with the authentication emails in supabase, these discussions/threads are worth noting for future reference:

• Comment: https://github.com/supabase/gotrue/issues/304#issuecomment-1022115983
  • Point (2) seems to describe a situation we would like to be in, with the proposed solution (a) resolving it in a different way than we envisioned (by relaying all emails through an email-provider).
  • If we would consider implementing (a) in the future:
  • We would have to examine how we would proceed with Supabase's convenient local-development setup - which currently uses InBucket - in conjunction with the hosted email provider.
  • According to the last comment on the thread (https://github.com/supabase/gotrue/issues/304#issuecomment-1475846336), Supabase is looking into parameterized HTTP hooks, and asks us to follow along on its changelog/newsletter.
  • Supabase has a guide on Auth Hooks, however I am not sure if this is the same thing.

[CvdL-UM]

Maybe we need to switch the logic around and ditch the emails through Supabase. Although convenient with InBucket, it does cause a split between our mails. Instead, we can send all emails through our SMTP provider and catch all the emails locally in a mailbox through our SMTP provider. So like @eensander proposed before, a SMTP .env setting for production and another for local development. This does create another dependency, but it might leave the choice of SMTP provider up to the person hosting Lawnotation him/herself.

To send emails when new tasks have been assigned we can also have a look at Supabase's Database Webhooks

[eensander]

@CvdL-UM: Maybe we need to switch the logic around and ditch the emails through Supabase. Although convenient with InBucket, it does cause a split between our mails. Instead, we can send all emails through our SMTP provider and catch all the emails locally in a mailbox through our SMTP provider. So like @eensander proposed before, a SMTP .env setting for production and another for local development.

I agree that sending all emails with SMTP might be the best option. In order to keep using InBucket, we could look into setting up a development script that launches:

1. Supabase's local development setup
   • pnpm supabase start
2. An isolated InBucket instance with Docker that attaches itself to the respective Docker network of the previous command
   • docker run (...) --network supabase_network_lawnotation-ui

     Notice: network name is constant since it is dependent on the config.toml's project_id as can be seen here.

3. Nuxt's local development server
   • pnpm dev

@CvdL-UM: This does create another dependency, but it might leave the choice of SMTP provider up to the person hosting Lawnotation him/herself.

If we only send emails over SMTP with a package such as nodemailer, we could remove the MailTrap package that this PR introduces, meaning the amount of dependencies would remain the same.

@CvdL-UM: To send emails when new tasks have been assigned we can also have a look at Supabase's Database Webhooks

That sounds like a good consideration. Although, perhaps some points to take into account:

• I think it would be best if we keep all logic for sending off emails in one place, where we can also utilize email-templates.
  • However, perhaps we could setup an API/HTTP endpoint (with tRPC?) that this database hook would execute every time an assignment is created.
• A second consideration is that when it could be difficult to trigger such database hook on every INSERT in the assignment-table, since the action of assigning a single user to a task usually creates multiple rows in the assignment-table for this user, and we don't want the user to receive an email for each row (read: document, for example) in that was inserted for one task