-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
feat(api): add workflow trigger identifier parity #6657
feat(api): add workflow trigger identifier parity #6657
Conversation
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.
The test "should not allow creating two workflows for the same user with the same name" will fail because we do allow workflows with the same name.
We need to clarify the terms: name
is not unique and can be duplicated, while workflowIdentifier
(based on the workflow name) cannot be duplicated.
Please note, that I’ve seen discussions across the product regarding this topic, but the current logic in the product is as follows:
- On the first workflow creation, say "Password Reset," if the user hasn't provided a custom trigger identifier, we generate a slug from the workflow name.
- On the second creation of a workflow with the same name ("Password Reset"), if the user hasn't provided a custom trigger identifier, we gracefully allow the same name but append a short ID to the slug.
When updating a workflow, we will throw an error if the user provides a trigger identifier that already exists in the system. This is because having two workflows with the same trigger identifier is invalid. We enforce this rule both in the application and the database layer, where MongoDB will throw an exception if we don’t validate it.
✅ Deploy Preview for novu-stg-vite-dashboard-poc ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
@@ -64,6 +64,10 @@ export class WorkflowCommonsFields { | |||
@IsDefined() | |||
name: string; | |||
|
|||
@IsString() | |||
@IsDefined() | |||
triggerIdentifier: string; |
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.
IMO we can refactor the legacy term and make it simplifier with identifier
what do you think?
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.
I agree!
private async workflowExistByExternalId(upsertCommand: UpsertWorkflowCommand) { | ||
const { environmentId } = upsertCommand.user; | ||
const workflowByDbId = await this.notificationTemplateRepository.findByTriggerIdentifier( | ||
environmentId, | ||
upsertCommand.workflowDto.name | ||
); | ||
|
||
return !!workflowByDbId; | ||
} |
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.
we don't need to validate because this logic is handled in the Create/Update workflow application-generic logic. so this call is duplicated.
(small note we enforce it on the database layer as well)
if (command.triggerIdentifier) { | ||
return command.triggerIdentifier; | ||
} |
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.
If provided, we will skip the internal generation. This is somewhat of a risk area, which is why I added a comment on the command parameter.
libs/application-generic/src/usecases/create-workflow/create-workflow.usecase.ts
Show resolved
Hide resolved
novu
@novu/client
@novu/framework
@novu/headless
@novu/js
@novu/node
@novu/notification-center
@novu/providers
@novu/react
@novu/react-native
@novu/shared
commit: |
@@ -188,28 +189,13 @@ export class UpsertWorkflowUseCase { | |||
description: workflowDto.description || '', | |||
tags: workflowDto.tags || [], | |||
critical: false, | |||
triggerIdentifier: `${slugify(workflowDto.name, { |
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 introduces a new term called triggerIdentifier
. Isn't this the same as the workflowId
? If yes, please rename accordingly.
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.
Moreover we need to use the same help slugifyIdentifier
helper
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 introduces a new term called triggerIdentifier.
this is not true, under the hood CreateWorkflow usecase is responsible for creation of
workflow.triggers.identifier
where workflow is NotificationTemplateEntity)
and triggers is NotificationTriggerEntity[]
In CreateWorkflow usecase context, i think we should provide it with more explicit terms if possible, until/if we decide to refactor our workflow entity
apps/api/src/app/workflows-v2/usecases/upsert-workflow/upsert-workflow.usecase.ts
Outdated
Show resolved
Hide resolved
libs/application-generic/src/usecases/create-workflow/create-workflow.usecase.ts
Show resolved
Hide resolved
@@ -243,6 +245,7 @@ function buildCreateWorkflowDto(nameSuffix: string): CreateWorkflowDto { | |||
return { | |||
__source: WorkflowCreationSourceEnum.EDITOR, | |||
name: TEST_WORKFLOW_NAME + nameSuffix, | |||
workflowId: `${slugifyName(TEST_WORKFLOW_NAME + nameSuffix)}`, |
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.
I think it's an antipattern to supply a slugified workflowId
during workflow creation, that concern should be handled in the API. Am I missing something?
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.
What changed? Why was the change needed?
Add trigger identifier parity with the v2 Workflows API CRUD.
Why? (Context)
Currently, we're missing some functionality that was available in v1, the
identifier
was missing in the DTO meaning the frontend was not able to provide it in the client.This ticket aims to address that gap.
Screenshots
Expand for optional sections
Related enterprise PR
Special notes for your reviewer