-
Notifications
You must be signed in to change notification settings - Fork 4k
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
fix: provide notification group on creation by blueprint #5296
fix: provide notification group on creation by blueprint #5296
Conversation
✅ Deploy Preview for dev-web-novu ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
…e-blueprint-on-cross-origin' into nv-3188-incorrect-creation-of-the-blueprint-on-cross-origin
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.
hey @djabarovgeorge, approving it! 🙌
The only thing that is bothering me is our decision to have a "central" place for managing the blueprints. Don't you think that it might be much simpler to maintain if we decide to split it to EU and US, like each region will be independent. Like to me I'm not sure if it's worth to have such logic and maintain it, if I can just spend few mins and create the same set of templates in any EU/US region. WDYT?
I believe it's better to keep the blueprints separate from the user environment. This means we shouldn't include any internal user identifiers in the blueprints. By keeping the creation of a workflow stateless and isolated within the user's environment, we prevent any dependencies on user-specific information. Providing isolated blueprints ensures those bugs don't occur. IMO managing two sources of truth could lead to additional maintenance and potential issues with alignment and future bugs. please note that in the future we could have more regions which could lead to more maintenance for us. |
…on-cross-origin # Conflicts: # apps/web/src/api/notification-templates.ts
What change does this PR introduce?
When creating a blueprint template, internal IDs like _notificationGroupId and _feedId are utilized. However, using these IDs may result in errors when generating templates for environments other than DEV and US, as the blueprint is extracted from these specific environments.
Why was this change needed?
Scenario of the issue:
An EU user receives a notification template (workflow) blueprint containing internal IDs. This blueprint is extracted from the US-Centralized blueprint storage. Upon attempting to create this workflow in the EU-API, the system encounters an error while trying to extract entities by their IDs, as these entities don’t exist in the EU environment.
Definition of Done