Consider the environment when generating the invite URLs

[rdimitrov]

Summary

The following PR:

• Adds a Minder base url field to the email server config section. This is used when generating the user invitation URL, so we can prefix it with the correct minder frontend, i.e. staging vs prod
• Adds the invite URL to the responses when an invite is created or updated
• Adds a noop email client in case there's no aws ses config present. This is helpful for local development where we don't expect having it. It will log the email content which was supposed to be sent and return nil
• Removed the wrapper and the interface since it felt obsolete. If someone wants to use another client, they can safely implement the events.Consumer interface and that should be enough. The message payload includes everything that is needed - email, subject, html and text bodies.
• Updates the minder base url to the example server config

Change Type

Mark the type of change your PR introduces:

• Bug fix (resolves an issue without affecting existing features)
• Feature (adds new functionality without breaking changes)
• Breaking change (may impact existing functionalities or require documentation updates)
• Documentation (updates or additions to documentation)
• Refactoring or test improvements (no bug fixes or new functionality)

Testing

Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.

Review Checklist:

• Reviewed my own code for quality and clarity.
• Added comments to complex or tricky code sections.
• Updated any affected documentation.
• Included tests that validate the fix or feature.
• Checked that related changes are merged.

[coveralls]

coverage: 51.884% (-0.1%) from 52.002%
when pulling 16d7d00 on invite-url
into ff2be84 on main.

[lukehinds]

I figure this is vendor agnostic and others could in time add for example a gmail mailchimp etc?

[rdimitrov]

Yeah. initially I had a wrapper and this interface -

// Service is the email service interface
type Service interface {
	SendEmail(ctx context.Context, to, subject, bodyHTML, bodyText string) error
}

But it felt obsolete since the watermill event message payload now includes everything that is needed for another client to be hooked up.

If we or someone else wants to add another email service provider, they have to implement the Register method (events.Consumer interface) and that would be enough.

[jhrozek]

Do we verify the URL is well-formed anywhere? It might make sense to use url.Parse and then also to join with the suffix.

[rdimitrov]

of course, good idea 👍

[rdimitrov]

Addressed it 👍 Also added the use of db transaction for both creating and updating an invite so we fail in case the base URL fails parsing.

[jhrozek]

I haven't been following this feature too closely, but why is the invite URL configurable at all? Shouldn't this be something set by the server?

[rdimitrov]

I think both are true, because the invite URL is generated on the backend side, but it is based on where the FE server is. I decided to pass this from the environment through the server config. Is this what you meant?

[jhrozek]

What I meant to ask is, is the invite URL something the user can affect or is it just given to the user in the reply? If it's just in the reply and the user can't change the invite base URL when they create the invite, then it's OK

[rdimitrov]

Ah, I see. No, the user has no control over the invite URL and how it's constructed 👍

[coveralls]

coverage: 51.833% (-0.2%) from 52.002%
when pulling a1c4afd on invite-url
into ff2be84 on main.