We would like to move away from the concept of finding and removing pending
jobs. The only place this is used is for album update notifications, and this
is done so that users who initially uploaded assets to an album will also
receive a notification if someone else then adds assets to the same album. This
can also be achieved with a job for each recipient. Multiple jobs also has the
advantage that it will scale better for albums with many users, it's possible
to send notifications concurrently, retries are possible without sending
duplicate notifications, and it's clear what recipient a job failed for.
* feat: use my.immich.app for externalDomain fallback
This is probably more useful than localhost.
* chore: remove port param
* fix: update expected value in tests
* fix: update expected value in e2e
Album update jobs will now wait five minutes to send. If a new image is added while that job is pending, the old job will be cancelled, and a new one will be enqueued for a minute.
This is to prevent a flood of notifications by dragging in images directly to the album, which adds them to the album one at a time.
Album updates now include a list of users to email, which is generally everybody except the updater. If somebody else updates the album within that minute, both people will get an album update email in a minute, as they both added images and the other should be notified.
* feat(server): add `react-mail` as mail template engine and `nodemailer`
* feat(server): add `smtp` related configs to `SystemConfig`
* feat(web): add page for SMTP settings
* feat(server): add `react-email.adapter`
This adapter render the React-Email into HTML and plain/text email.
The output is set as the body of the email.
* feat(server): add `MailRepository` and `MailService`
Allow to use the NestJS-modules-mailer module to send SMTP emails.
This is the base transport for the `NotificationRepository`
* feat(server): register the job dispatcher and Job for async email
This allows to queue email sending jobs for the `EmailService`.
* feat(server): add `NotificationRepository` and `NotificationService`
This act as a middleware to properly route the notification to the right transport.
As POC I've only implemented a simple SMTP transport.
* feat(server): add `welcome` email template
* feat(server): add the first notification on `createUser` in `UserService`
This trigger an event for the `NotificationRepository` that once processes
by using the global config and per-user config will carry the payload to the right notification transport.
* chore: clean up
* chore: clean up web
* fix: type errors"
* fix package lock
* fix mail sending, option to ignore certs
* chore: open api
* chore: clean up
* remove unused import
* feat: email feature flag
* chore: remove unused interface
* small styling
---------
Co-authored-by: Jason Rasmussen <jrasm91@gmail.com>
Co-authored-by: Daniel Dietzler <mail@ddietzler.dev>
Co-authored-by: Alex Tran <alex.tran1502@gmail.com>
