-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1040 prototype email gateway #1048
base: master
Are you sure you want to change the base?
Conversation
…registration email using a very draft version of the email template
…rst registered. Simplified gateway configuration structures. Added dummy email sender (to debug templating mostly).
…d in predefined config
…ing to configuration
…lier created (so that we swallow new emails from config!)
|
||
let account_repo = from_catalog_n!(ctx, dyn AccountRepository); | ||
match account_repo | ||
.update_account_email(&self.account.id, new_email.clone()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this go through a use case and do auth before changing email? Currently it looks like this will allow anyone (including anonymous users) to change any other account's email.
odf = { workspace = true } | ||
time-source = { workspace = true } | ||
|
||
askama = { version = "0.12" } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I expected to see this dependency in an infra layer, not in a domain crate
@@ -23,12 +23,15 @@ doctest = false | |||
|
|||
[dependencies] | |||
database-common = { workspace = true } | |||
email-gateway = { workspace = true } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like an odd coupling. I expected that in account domain layer we only emit messages about account life cycle and react to them elsewhere.
The fact that these messages trigger an email notification is IMO neither a account domain concern, nor even an infra-level account service concern. Sending emails notifs is more like Kamu Node-level business logic concern.
I would suggest moving the templating and email sending into a crate in kamu-node
. Seems like one of those things that we'll never need on CLI level.
let rendered_registration_body = registration_email.render().unwrap(); | ||
|
||
self.email_sender | ||
.send_email( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, as per my other comment this looks completely out of place in account domain crate.
Description
Closes: #1040
Integration of email gateway (Postmark):
EmailSender
crate and prototypedPostmark
-based implementationaskoma
templating engine and defined base HTML-rich template for all emailsAdded GQL suport to query and update email on the currently logged account.
Emails are mandatory for Kamu accounts now:
Checklist before requesting a review