Skip to content
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

Change docs regarding sending emails for custom events #4

Open
NicolasGorga opened this issue Aug 12, 2024 · 2 comments
Open

Change docs regarding sending emails for custom events #4

NicolasGorga opened this issue Aug 12, 2024 · 2 comments

Comments

@NicolasGorga
Copy link
Contributor

Hello,

One of the problems I found with original plugin's docs, is the statement regarding sending emails for custom events. By reading the docs, one would assume that just by adding the custom event template key to plugin options, and corresponding template Sendgrid id as value, emails would be sent.

This alone won't fire an email, since the event is never registered against the NotificationProvider. I would suggest two alternatives:

1- Either change the README, indicating that apart from setting this configuration in plugin options, one needs to create a Subscriber and register the event against the Sendgrid provider, similar to order loader
2- Or change the loader code, to dynamically register the events taken from the plugiun options, against the sendgrid provider. This way, firing emails for custom events is as easy as firing them for the already defined ones, since you just add the config to plugin options and don't need to worry about creating the loader.

@luluhoc
Copy link
Owner

luluhoc commented Aug 12, 2024

@NicolasGorga You can create a PR for the 1st option, cause I think someone should use the SendGrid service in their custom event rather than overcomplicate the settings.

@NicolasGorga
Copy link
Contributor Author

Why do you see it as "overcomplicating the settings"? With the second option, the current behavior for plugin options would remain the same. Moreover, the end user wouldn't need to do an extra step of creating a loader for events that fall outside of the current default events registered by the plugin and that are also harcoded.

With this solution one would only need to define the keys in the plugin options as current, but not limited to a subset of events, but rather have access to all existent events + custom ones

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants