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

feat(api): add workflow trigger identifier parity #6657

Merged

Conversation

djabarovgeorge
Copy link
Contributor

@djabarovgeorge djabarovgeorge commented Oct 9, 2024

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.
image

This ticket aims to address that gap.

Screenshots

Expand for optional sections

Related enterprise PR

Special notes for your reviewer

Copy link

linear bot commented Oct 9, 2024

Copy link
Contributor Author

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.

Copy link

netlify bot commented Oct 9, 2024

Deploy Preview for novu-stg-vite-dashboard-poc ready!

Name Link
🔨 Latest commit 48c0c00
🔍 Latest deploy log https://app.netlify.com/sites/novu-stg-vite-dashboard-poc/deploys/670e923f6a52a60008ac6217
😎 Deploy Preview https://deploy-preview-6657--novu-stg-vite-dashboard-poc.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

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;
Copy link
Contributor Author

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree!

Comment on lines -199 to -211
private async workflowExistByExternalId(upsertCommand: UpsertWorkflowCommand) {
const { environmentId } = upsertCommand.user;
const workflowByDbId = await this.notificationTemplateRepository.findByTriggerIdentifier(
environmentId,
upsertCommand.workflowDto.name
);

return !!workflowByDbId;
}
Copy link
Contributor Author

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)

Comment on lines +123 to +125
if (command.triggerIdentifier) {
return command.triggerIdentifier;
}
Copy link
Contributor Author

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.

Copy link

pkg-pr-new bot commented Oct 10, 2024

Open in Stackblitz

novu

pnpm add https://pkg.pr.new/novuhq/novu@6657

@novu/client

pnpm add https://pkg.pr.new/novuhq/novu/@novu/client@6657

@novu/framework

pnpm add https://pkg.pr.new/novuhq/novu/@novu/framework@6657

@novu/headless

pnpm add https://pkg.pr.new/novuhq/novu/@novu/headless@6657

@novu/js

pnpm add https://pkg.pr.new/novuhq/novu/@novu/js@6657

@novu/node

pnpm add https://pkg.pr.new/novuhq/novu/@novu/node@6657

@novu/notification-center

pnpm add https://pkg.pr.new/novuhq/novu/@novu/notification-center@6657

@novu/providers

pnpm add https://pkg.pr.new/novuhq/novu/@novu/providers@6657

@novu/react

pnpm add https://pkg.pr.new/novuhq/novu/@novu/react@6657

@novu/react-native

pnpm add https://pkg.pr.new/novuhq/novu/@novu/react-native@6657

@novu/shared

pnpm add https://pkg.pr.new/novuhq/novu/@novu/shared@6657

commit: 48c0c00

@@ -188,28 +189,13 @@ export class UpsertWorkflowUseCase {
description: workflowDto.description || '',
tags: workflowDto.tags || [],
critical: false,
triggerIdentifier: `${slugify(workflowDto.name, {
Copy link
Contributor

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.

Copy link
Contributor

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

Copy link
Contributor Author

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

libs/application-generic/src/utils/slugify-identifier.ts Outdated Show resolved Hide resolved
@djabarovgeorge djabarovgeorge merged commit 2e87ab7 into next Oct 15, 2024
41 checks passed
@djabarovgeorge djabarovgeorge deleted the nv-4468-create-trigger-identifier-parity-with-v2-workflows branch October 15, 2024 17:37
@@ -243,6 +245,7 @@ function buildCreateWorkflowDto(nameSuffix: string): CreateWorkflowDto {
return {
__source: WorkflowCreationSourceEnum.EDITOR,
name: TEST_WORKFLOW_NAME + nameSuffix,
workflowId: `${slugifyName(TEST_WORKFLOW_NAME + nameSuffix)}`,
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point i made it like this because of the following design where the client has validation.

image

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

Successfully merging this pull request may close these issues.

3 participants