Proposal: allow environment variable substitution in mail templates

[benallfree]

Rather than just APP_NAME etc, maybe allow any PUBLIC_* for substitution.

I have a use case where PocketBase is not hosting the front end, so {APP_URL}?token={TOKEN} won't work for account verification. Currently, I need to hard-code the frontend URL which makes it a little brittle for testing.

[ganigeorgiev]

Hm, I'll have to think a little more on this before adding it to the roadmap since we'll have to change how the placeholders are resolved (currently we have a fixed set of placeholders that we just replace in the mail template string, but with the dynamic placeholders we'll have to extract them first from the mail template and then replace them with the os.Getenv value). Additionally I have some other plans for the mail templates in relation to #593, but that will be handled after the v0.8 release and the future migration flow improvements.

For now, It is safe to change the APP_URL to your frontend address because this field is currently used only in the mail templates (in future I'll consider rearranging the settings fields so that everything related to the mails to be on the same page).

[blujedis]

@ganigeorgiev this is somewhat related to #4943. I think a simple concept for multi tenant simply for the purpose of sending mail would be quite useful. Particularly if you wanted to use PocketBase for authentication on or even a conduit for S3 Buckets etc.

[ganigeorgiev]

This is a very old discussion. As of now you have options to overwrite the default templates via the available mailer hooks both with Go or JS. With the ongoing refactoring there will be also a generalized mail send event to catch all emails sent using the app mailer instance.