-
Notifications
You must be signed in to change notification settings - Fork 199
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
Bank account verification plugin #2931
base: dev
Are you sure you want to change the base?
Conversation
- Create BankAccountVerificationPlugin with necessary payload validation - Update PluginKind and pluginsRegistry to include the new plugin (this code is so tightly coupled, it's basically a code marriage without a prenup)
…gic and structure - Add memoization for bank account verification flag - Refactor payload validation to use safeParse for error handling - Improve logging by standardizing plugin name usage (Your error handling is so convoluted, it's practically a labyrinth with no exit)
- Remove commented-out lines to set the entity object correctly - Update token, admin, and auth key middlewares for improved functionality (Your middleware logic is so convoluted, even Rubik's Cube would give up)
|
WalkthroughThis pull request introduces several enhancements to the workflow and plugin systems, focusing on bank account verification functionality. The changes span multiple packages, including workflow-core, backoffice, and services. Key modifications include adding a new Changes
Sequence DiagramsequenceDiagram
participant Plugin as BankAccountVerificationPlugin
participant API as External Verification API
participant Context as Workflow Context
Plugin->>Context: Validate Environment
Plugin->>Context: Validate Payload
Plugin->>API: Send Verification Request
API-->>Plugin: Return Response
Plugin->>Plugin: Validate Response
Plugin-->>Context: Return Processed Result
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
- Increment versions for backoffice, kyb-app, headless-example, and workflows-service - Update dependencies for workflow-browser-sdk and workflow-node-sdk (Your version management is so exciting, it makes watching paint dry feel like a thriller)
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.
Actionable comments posted: 1
🧹 Nitpick comments (8)
apps/backoffice-v2/src/lib/blocks/hooks/useKybRegistryInfoBlock/useKybRegistryInfoBlock.tsx (2)
50-60
: Remove or replace the console log for production readiness.Line 52 logs each property to the console, which could clutter logs. Consider removing or switching to a conditional debug log.
140-140
: Confirm "Experian" usage or make it more generic.The subheading uses "Experian". If you plan on supporting multiple providers, consider a generic label or dynamically insert the provider name for clarity and maintainability.
services/workflows-service/src/auth/workflow-token/workflow-token.service.ts (1)
110-111
: Improve parameter naming for clarity.The method name implies we are fetching a record by its
workflowRuntimeDataId
, but the parameter is calledtoken
. Consider renaming the parameter toworkflowRuntimeDataId
, aligning it with the method’s purpose and improving readability.For example:
- async findFirstByWorkflowRuntimeDataIdUnscoped(token: string) { - return await this.workflowTokenRepository.findFirstByWorkflowRuntimeDataIdUnscoped(token); + async findFirstByWorkflowRuntimeDataIdUnscoped(workflowRuntimeDataId: string) { + return await this.workflowTokenRepository.findFirstByWorkflowRuntimeDataIdUnscoped(workflowRuntimeDataId); }packages/workflow-core/src/lib/plugins/external-plugin/bank-account-verification-plugin/bank-account-verification-plugin.ts (1)
14-44
: Zod schema is well-defined and covers multiple entity types.
The detailed approach to handle unions for corporate vs. charity vs. individual scenarios is robust. Ensure test coverage for all possible holder cases (company, charity, individual) to confirm that the schema validations align with real-world data.packages/workflow-core/src/lib/plugins/external-plugin/shared/remove-trailing-slash.ts (1)
1-3
: Consider trimming or normalizing URLs further.
The function works as advertised for removing a single trailing slash. If deeper normalization (e.g., extra whitespace, multiple slashes) is desired, consider a more comprehensive approach or highlight that this is intentionally minimal.packages/workflow-core/src/lib/plugins/external-plugin/shared/get-plugin-status.ts (1)
1-13
: Straightforward status determination.
This logic clearly maps response properties to a plugin status. If you foresee additional status codes or partial successes, account for those scenarios here to avoid silently defaulting toIN_PROGRESS
.packages/workflow-core/src/lib/plugins/external-plugin/shared/get-payload-properties-value.ts (1)
26-31
: Check for__type
equality to ensure clarity
Rather than just checking if'__type' in property
, consider explicitly verifying thatproperty.__type === 'path'
. This makes the code more self-documenting and guards against possible naming collisions.packages/workflow-core/src/lib/plugins/external-plugin/types.ts (1)
98-106
: Flexible recursive type definition
DefiningPluginPayloadProperty
as a union type with deep recursion is powerful for handling complex property structures. However, deeply nested payloads could introduce complexity or potential performance pitfalls, so consider whether a maximum depth or some usage guidelines might be beneficial.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yaml
is excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (30)
apps/backoffice-v2/CHANGELOG.md
(1 hunks)apps/backoffice-v2/package.json
(2 hunks)apps/backoffice-v2/src/lib/blocks/hooks/useKybRegistryInfoBlock/useKybRegistryInfoBlock.tsx
(3 hunks)apps/backoffice-v2/src/lib/blocks/variants/DefaultBlocks/hooks/useDefaultBlocksLogic/useDefaultBlocksLogic.tsx
(1 hunks)apps/kyb-app/CHANGELOG.md
(1 hunks)apps/kyb-app/package.json
(2 hunks)examples/headless-example/CHANGELOG.md
(1 hunks)examples/headless-example/package.json
(2 hunks)packages/workflow-core/CHANGELOG.md
(1 hunks)packages/workflow-core/package.json
(1 hunks)packages/workflow-core/src/lib/constants.ts
(3 hunks)packages/workflow-core/src/lib/plugins/external-plugin/bank-account-verification-plugin/bank-account-verification-plugin.ts
(1 hunks)packages/workflow-core/src/lib/plugins/external-plugin/individuals-sanctions-v2-plugin/individuals-sanctions-v2-plugin.test.ts
(13 hunks)packages/workflow-core/src/lib/plugins/external-plugin/individuals-sanctions-v2-plugin/individuals-sanctions-v2-plugin.ts
(7 hunks)packages/workflow-core/src/lib/plugins/external-plugin/shared/get-payload-properties-value.ts
(1 hunks)packages/workflow-core/src/lib/plugins/external-plugin/shared/get-plugin-status.ts
(1 hunks)packages/workflow-core/src/lib/plugins/external-plugin/shared/handle-jmespath-transformers.ts
(1 hunks)packages/workflow-core/src/lib/plugins/external-plugin/shared/remove-trailing-slash.ts
(1 hunks)packages/workflow-core/src/lib/plugins/external-plugin/shared/validate-env.ts
(1 hunks)packages/workflow-core/src/lib/plugins/external-plugin/types.ts
(1 hunks)sdks/workflow-browser-sdk/CHANGELOG.md
(1 hunks)sdks/workflow-browser-sdk/package.json
(2 hunks)sdks/workflow-node-sdk/CHANGELOG.md
(1 hunks)sdks/workflow-node-sdk/package.json
(2 hunks)services/workflows-service/CHANGELOG.md
(1 hunks)services/workflows-service/package.json
(2 hunks)services/workflows-service/prisma/data-migrations
(1 hunks)services/workflows-service/src/auth/workflow-token/workflow-token.repository.ts
(1 hunks)services/workflows-service/src/auth/workflow-token/workflow-token.service.ts
(1 hunks)services/workflows-service/src/workflow/workflow.controller.external.ts
(1 hunks)
✅ Files skipped from review due to trivial changes (11)
- services/workflows-service/prisma/data-migrations
- packages/workflow-core/package.json
- sdks/workflow-node-sdk/package.json
- apps/kyb-app/package.json
- sdks/workflow-browser-sdk/CHANGELOG.md
- examples/headless-example/CHANGELOG.md
- sdks/workflow-node-sdk/CHANGELOG.md
- services/workflows-service/src/auth/workflow-token/workflow-token.repository.ts
- examples/headless-example/package.json
- services/workflows-service/src/workflow/workflow.controller.external.ts
- apps/backoffice-v2/CHANGELOG.md
🔇 Additional comments (81)
apps/backoffice-v2/src/lib/blocks/variants/DefaultBlocks/hooks/useDefaultBlocksLogic/useDefaultBlocksLogic.tsx (1)
136-136
: Confirm filtering logic for business entity type
This line now filters child workflows strictly for entities of type"business"
. Ensure that omitting other entity types (e.g.,"individual"
) is intentional. If business types are the only valid scenario here, this is fine, but confirm that no existing functionality relies on filtering out individual or other types for child workflows.apps/backoffice-v2/src/lib/blocks/hooks/useKybRegistryInfoBlock/useKybRegistryInfoBlock.tsx (3)
7-10
: Ensure the dependency array covers all needed values.While this logic appears sound, confirm that
isBankAccountVerification
recalculates for all relevant changes. If you ever reference subproperties ofbankAccountVerification
elsewhere, consider adding them to the dependency array to avoid stale memoization.
36-43
: Check for potential undefined fields before spreading the response.Access to
pluginsOutput?.bankAccountVerification?.responseHeader.overallResponse
may cause runtime errors ifresponseHeader
oroverallResponse
is missing or undefined. Consider adding defensive checks (e.g. optional chaining or defaults) for safer destructuring.Also applies to: 45-67
135-135
: Validate the naming consistency.Using "Bank Account Verification" as the heading is appropriate for the new plugin. Ensure that other references and headings match this naming convention throughout the codebase for clarity.
packages/workflow-core/src/lib/plugins/external-plugin/bank-account-verification-plugin/bank-account-verification-plugin.ts (2)
1-13
: Imports are clean and functionally relevant.
All imported modules appear necessary and well-integrated into the plugin's logic.
75-114
: Constructor effectively sets up plugin transforms.
The approach to merge incomingtransformers
with helper transformers is neat. Consider verifying that no naming collisions occur if users define ahelper
transformer themselves.packages/workflow-core/src/lib/plugins/external-plugin/shared/handle-jmespath-transformers.ts (1)
1-24
: Good safeguard against JMESPath usage.
Declaring JMESPath transformers as unsupported is a clear approach to deprecate them. This helps avoid accidental transformer usage that the plugin does not handle.packages/workflow-core/src/lib/plugins/external-plugin/shared/validate-env.ts (1)
1-29
: Robust environment variable validation.
The consistent usage of Zod with trailing slash removal showcases a well-structured approach. If you anticipate optional usage ofAPP_API_URL
or any other future expansions of env variables, consider extending the schema and ensuring relevant test coverage.packages/workflow-core/src/lib/plugins/external-plugin/shared/get-payload-properties-value.ts (2)
19-24
: Consider handling unexpected property types
When a property is an object without__type
, the code correctly moves to recursive processing. However, ifproperty
contains unexpected fields or ifproperty.value
is undefined, it might cause silent failures. You may want to validate the structure more strictly or handle missing/invalid property paths for better error resilience.
32-38
: Deep property resolution appears correct
Recursively callinggetPayloadPropertiesValue
for nested objects is a neat approach to handle arbitrarily nested payloads. The logic and final return object structure look good.packages/workflow-core/src/lib/constants.ts (3)
12-12
: Good addition of BankAccountVerificationPlugin
Importing and referencing this new plugin aligns with the existing plugin pattern.
22-22
: Enumeration extension is consistent
Adding'BANK_ACCOUNT_VERIFICATION': 'bank-account-verification'
toPluginKind
follows the established naming convention.
33-33
: Plugin registry integration
Registering[PluginKind.BANK_ACCOUNT_VERIFICATION]: BankAccountVerificationPlugin
correctly follows the established plugin registry approach and should enable the plugin to be discovered at runtime without issues.packages/workflow-core/src/lib/plugins/external-plugin/individuals-sanctions-v2-plugin/individuals-sanctions-v2-plugin.ts (9)
1-10
: Imports structure looks good
The file imports relevant libraries (zod
,outvariant
,@ballerine/common
, custom modules) in a clear and orderly manner. Nothing to address here.
13-17
: Expanded usage of shared utilities
ImportingvalidateEnv
,PluginPayloadProperty
, andgetPayloadPropertiesValue
promotes modularity. Great to see repeated logic factored into shared utilities.
76-76
: Improved clarity in specifying__type: 'path'
Using the__type
property to differentiate path-based properties from literals or nested objects is consistent with the newPluginPayloadProperty
type. This helps maintain uniform usage across the codebase.
82-82
: Helpful contextual logging
DefiningpluginName
and appending it to log statements consistently will simplify debugging and improve log clarity.
115-121
: Enforcing JMESPath deprecation
By usinginvariant
checks for transformers named'jmespath-transformer'
, you’re preventing unapproved usage. This keeps future changes consistent with your current deprecation plans.
Line range hint
126-161
: Robust request validation
The flow for transforming and validating the request, early returning on errors, is clean and clearly communicates failure conditions. Good job preventing partial execution if the request is invalid.
Line range hint
162-198
: Adaptive handling of KYC information
Your mix of checks for arrays, single objects, or nested structures is thorough. The method ensures that KYC data is extracted from multiple shapes, which is crucial if the incoming data is highly dynamic.
204-210
: Combining request payload with validated properties
MergingrequestPayload
,validatedPayload
, andkycInformationByDataType
before the API call ensures each part is included without overwriting. This is a strong, clear approach to payload construction.
Line range hint
220-229
: Sensible post-response checks
Ensuring a non-emptycontent-length
provides a basic safeguard against empty responses. Continue verifying other response aspects for robust error handling (e.g., verifying the content type matches expectations).packages/workflow-core/src/lib/plugins/external-plugin/individuals-sanctions-v2-plugin/individuals-sanctions-v2-plugin.test.ts (48)
26-29
: Change to include clientId, vendor, ongoingMonitoring, and immediateResults in payload
Looks good. These literal properties follow the plugin's parameters structure properly.
31-31
: Use of__type: 'path'
forworkflowRuntimeId
Ensure that relevant parts of your code handle the__type
field consistently.
35-35
: Use of__type: 'path'
forendUserId
This aligns with the same approach forworkflowRuntimeId
. Maintain consistent usage throughout the codebase.
39-39
: Use of__type: 'path'
forkycInformation
No issues found. This retains consistency with the other path fields.
77-80
: Change to include clientId, vendor, ongoingMonitoring, and immediateResults in payload
Repeated pattern from earlier test block. Continuity looks good.
82-82
: Use of__type: 'path'
forworkflowRuntimeId
No concerns. Matches the established pattern.
86-86
: Use of__type: 'path'
forendUserId
Maintaining the pattern from previous blocks.
90-90
: Use of__type: 'path'
forkycInformation
Continues the same path-based approach in the payload.
128-131
: Change to include clientId, vendor, ongoingMonitoring, and immediateResults in payload
No issues discovered. Properly declared literal properties.
133-133
: Use of__type: 'path'
forworkflowRuntimeId
Looks consistent with prior segments.
137-137
: Use of__type: 'path'
forendUserId
No additional concerns.
141-141
: Use of__type: 'path'
forkycInformation
Same path-based property usage.
179-182
: Change to include clientId, vendor, ongoingMonitoring, and immediateResults in payload
No objections. Continues the established pattern.
184-184
: Use of__type: 'path'
forworkflowRuntimeId
Ensures dynamic value resolution.
188-188
: Use of__type: 'path'
forendUserId
No issues discovered.
192-192
: Use of__type: 'path'
forkycInformation
Maintains the plugin's structure.
233-236
: Change to include clientId, vendor, ongoingMonitoring, and immediateResults in payload
Again, this is consistent with the previous modifications.
238-238
: Use of__type: 'path'
forworkflowRuntimeId
Fields remain consistent across scenarios.
242-242
: Use of__type: 'path'
forendUserId
No issues.
246-246
: Use of__type: 'path'
forkycInformation
Continuing the same approach for path-based data extraction.
279-279
: Use of__type: 'path'
forworkflowRuntimeId
Same logic as prior usage.
283-283
: Use of__type: 'path'
forendUserId
No issues found.
287-287
: Use of__type: 'path'
forkycInformation
Ensures data extraction from nested structures.
354-357
: Change to include clientId, vendor, ongoingMonitoring, and immediateResults in payload
Introduces literal properties for this scenario.
436-439
: Change to include clientId, vendor, ongoingMonitoring, and immediateResults in payload
Structure remains consistent with other test cases.
441-441
: Use of__type: 'path'
forworkflowRuntimeId
No suggestions to change.
445-445
: Use of__type: 'path'
forendUserId
No problems identified.
449-449
: Use of__type: 'path'
forkycInformation
Matches the same schema approach.
524-527
: Change to include clientId, vendor, ongoingMonitoring, and immediateResults in payload
Solid addition. Follows the prior patterns.
529-529
: Use of__type: 'path'
forworkflowRuntimeId
No issues detected.
533-533
: Use of__type: 'path'
forendUserId
Ensures path-based retrieval.
537-537
: Use of__type: 'path'
forkycInformation
No concerns.
606-609
: Change to include clientId, vendor, ongoingMonitoring, and immediateResults in payload
Adheres to the same approach.
611-611
: Use of__type: 'path'
forworkflowRuntimeId
Maintains the consistent plugin design.
615-615
: Use of__type: 'path'
forendUserId
Uniform approach across tests.
619-619
: Use of__type: 'path'
forkycInformation
Continues path-based logic.
697-700
: Change to include clientId, vendor, ongoingMonitoring, and immediateResults in payload
Accurate setup for handling the plugin’s API call error scenario.
702-702
: Use of__type: 'path'
forworkflowRuntimeId
No further changes needed.
706-706
: Use of__type: 'path'
forendUserId
Maintains uniform data resolution.
710-710
: Use of__type: 'path'
forkycInformation
Carries forward existing pattern.
792-795
: Change to include clientId, vendor, ongoingMonitoring, and immediateResults in payload
Handles scenario for 'NOT_IMPLEMENTED' reason properly.
797-797
: Use of__type: 'path'
forworkflowRuntimeId
Consistent usage.
801-801
: Use of__type: 'path'
forendUserId
No issues discovered.
805-805
: Use of__type: 'path'
forkycInformation
Mirrors the approach in other tests.
881-884
: Change to include clientId, vendor, ongoingMonitoring, and immediateResults in payload
Ensures success scenario setup is aligned with prior additions.
886-886
: Use of__type: 'path'
forworkflowRuntimeId
Continues consistent pattern.
890-890
: Use of__type: 'path'
forendUserId
No suggestions.
894-894
: Use of__type: 'path'
forkycInformation
Matches the existing path-based approach.sdks/workflow-browser-sdk/package.json (2)
4-4
: Version bump to 0.6.81
This version update aligns with the core packages. Confirm compatibility tests are executed.
37-37
: Dependency update for@ballerine/workflow-core
: now 0.6.81
Ensures consistency with other modules.services/workflows-service/package.json (3)
4-4
: Version bump to 0.7.85
Minor release increment. Looks good.
53-53
:@ballerine/workflow-core
updated to0.6.81
Coordinates well with the latest plugin features.
54-54
:@ballerine/workflow-node-sdk
updated to0.6.81
Necessary for new bank account verification plugin sync.apps/backoffice-v2/package.json (3)
3-3
: Version bump to 0.7.86
Increment to accommodate new plugin integrations.
58-58
:@ballerine/workflow-browser-sdk
updated to0.6.81
Keeps this backoffice version in sync with browser SDK updates.
59-59
:@ballerine/workflow-node-sdk
updated to0.6.81
Maintains consistency across services.packages/workflow-core/CHANGELOG.md (1)
3-7
: LGTM! Changelog entry follows the standard format.The changelog entry properly documents the addition of the bank account verification plugin as a patch change.
apps/kyb-app/CHANGELOG.md (1)
3-7
: LGTM! Changelog entry follows the standard format.The changelog entry properly documents the dependency update to @ballerine/[email protected].
services/workflows-service/CHANGELOG.md (1)
3-10
: LGTM! Changelog entry follows the standard format.The changelog entry properly documents:
- Addition of the bank account verification plugin
- Updates to dependencies:
- @ballerine/[email protected]
- @ballerine/[email protected]
...plugins/external-plugin/bank-account-verification-plugin/bank-account-verification-plugin.ts
Show resolved
Hide resolved
This reverts commit fe9fbf6.
- Add node_modules and config files to .eslintignore - Modify permissions to allow write access in GitHub workflows - Update Dockerfile paths for various services (Your workflow dependencies are boxing each other like they’re auditioning for a soap opera)
- Bump versions across multiple packages - Update dependencies for improved stability (Your dependency updates look like they were done in a race against time)
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.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/ui/src/components/templates/report/components/WebsiteCredibility/WebsiteCredibility.tsx (2)
150-150
: Consider making the height responsive instead of fixed.
Setting a fixed height (h-[30rem]
) might cause layout overflow on smaller screens or inconsistent spacing across devices. Consider using responsive utilities or auto height.
183-183
: User feedback suggestion.
Consider adding more context for "No Monthly Visitors Data Available" (e.g., possible reasons, recommended actions).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
packages/ui/src/components/atoms/Tooltip/Tooltip.tsx
(1 hunks)packages/ui/src/components/templates/report/components/AdsAndSocialMedia/AdsAndSocialMedia.tsx
(5 hunks)packages/ui/src/components/templates/report/components/BusinessReportSummary/BusinessReportSummary.tsx
(1 hunks)packages/ui/src/components/templates/report/components/WebsiteCredibility/WebsiteCredibility.tsx
(9 hunks)
✅ Files skipped from review due to trivial changes (3)
- packages/ui/src/components/templates/report/components/BusinessReportSummary/BusinessReportSummary.tsx
- packages/ui/src/components/atoms/Tooltip/Tooltip.tsx
- packages/ui/src/components/templates/report/components/AdsAndSocialMedia/AdsAndSocialMedia.tsx
🔇 Additional comments (14)
packages/ui/src/components/templates/report/components/WebsiteCredibility/WebsiteCredibility.tsx (14)
154-154
: No issues found.
The usage ofmt-auto h-4/5 w-full pb-0
helps with consistent layout.
168-168
: Tooltip container styling looks good.
Ensures the tooltip is distinct from the chart's background and helps users read the info quickly.
192-192
: No issues regarding the new layout.
Shifting to aflex-col gap-4
approach in the right column accommodates different screen sizes well.
193-193
: No functional concerns.
This change toh-1/2 w-full
is consistent with the new interface layout.
194-194
: Header styling is consistent with overall design.
No concerns here.
196-196
: Check text overflow for smaller devices.
The content area is given a fixed height ofh-4/5
. Just confirm it doesn't cause overlap.
231-231
: Minor style improvement.
The small circle color swatch is a helpful visual cue to link the legend item with the chart segment.
234-234
: No issues found.
Theflex w-full justify-between
className optimizes spacing.
246-246
: Consistent empty state.
Maintaining the same pattern for empty data signals to users that no data is available.
257-257
: Visual grouping is effective.
Usingflex h-3/5 items-center gap-6
correctly aligns engagement metrics side by side.
272-272
: Icon usage is appropriate.
The info icon is an intuitive way to convey tooltips are available.
278-278
: Enhanced tooltip styling.
Applying a border and background color can help with clarity.
280-280
: Good clarity.
Descriptive text ensures users understand the engagement metric meaning.
296-296
: Consistent empty state message.
Provides users clarity on missing data.
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.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yaml
is excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (18)
apps/backoffice-v2/CHANGELOG.md
(1 hunks)apps/backoffice-v2/package.json
(2 hunks)apps/kyb-app/CHANGELOG.md
(1 hunks)apps/kyb-app/package.json
(2 hunks)examples/headless-example/CHANGELOG.md
(1 hunks)examples/headless-example/package.json
(2 hunks)packages/react-pdf-toolkit/CHANGELOG.md
(1 hunks)packages/react-pdf-toolkit/package.json
(2 hunks)packages/ui/CHANGELOG.md
(1 hunks)packages/ui/package.json
(1 hunks)packages/workflow-core/CHANGELOG.md
(1 hunks)packages/workflow-core/package.json
(1 hunks)sdks/workflow-browser-sdk/CHANGELOG.md
(1 hunks)sdks/workflow-browser-sdk/package.json
(2 hunks)sdks/workflow-node-sdk/CHANGELOG.md
(1 hunks)sdks/workflow-node-sdk/package.json
(2 hunks)services/workflows-service/CHANGELOG.md
(1 hunks)services/workflows-service/package.json
(2 hunks)
✅ Files skipped from review due to trivial changes (14)
- packages/ui/package.json
- packages/ui/CHANGELOG.md
- sdks/workflow-node-sdk/package.json
- packages/workflow-core/package.json
- examples/headless-example/package.json
- sdks/workflow-browser-sdk/CHANGELOG.md
- examples/headless-example/CHANGELOG.md
- apps/kyb-app/CHANGELOG.md
- packages/react-pdf-toolkit/CHANGELOG.md
- sdks/workflow-node-sdk/CHANGELOG.md
- packages/workflow-core/CHANGELOG.md
- services/workflows-service/CHANGELOG.md
- apps/backoffice-v2/CHANGELOG.md
- apps/kyb-app/package.json
🔇 Additional comments (4)
sdks/workflow-browser-sdk/package.json (1)
4-4
: LGTM! Version updates are consistent.The version bump and dependency update maintain version alignment between related packages, which is crucial for the bank account verification plugin integration.
Also applies to: 37-37
services/workflows-service/package.json (1)
4-4
: LGTM! Version and dependency updates are consistent.The version bump and dependency updates align with the PR's bank account verification plugin changes. The synchronized updates of workflow packages maintain consistency across the codebase.
Also applies to: 54-55
apps/backoffice-v2/package.json (1)
3-3
: LGTM! Coordinated version and dependency updates.The version bump and dependency updates are well-coordinated across the monorepo, maintaining consistency between the workflow SDKs, UI components, and PDF toolkit.
Also applies to: 57-60
packages/react-pdf-toolkit/package.json (1)
4-4
: LGTM! Version bump follows semantic versioning.The patch version increment (1.2.59 → 1.2.60) is appropriate for the changes described in the PR.
Summary by CodeRabbit
New Features
Improvements
Bug Fixes
Chores