-
Notifications
You must be signed in to change notification settings - Fork 4
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: sfmc v2 onboarding #1868
base: develop
Are you sure you want to change the base?
feat: sfmc v2 onboarding #1868
Conversation
WalkthroughA new configuration system for Salesforce Marketing Cloud (SFMC) version 2 has been introduced. The implementation includes three primary configuration files: a database configuration ( Changes
Sequence DiagramsequenceDiagram
participant User
participant UIConfig
participant SchemaValidator
participant DBConfig
User->>UIConfig: Enter Connection Details
UIConfig->>SchemaValidator: Validate Input
SchemaValidator-->>UIConfig: Validation Result
alt Validation Successful
UIConfig->>DBConfig: Save Configuration
DBConfig-->>UIConfig: Configuration Saved
else Validation Failed
UIConfig->>User: Display Error Messages
end
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 (
|
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 (4)
test/data/validation/destinations/sfmc_v2.json (2)
4-6
: Ensure sensitive fields are properly masked.The
clientId
,clientSecret
, andsubDomain
fields contain sample values. While they appear to be masked, consider using consistent masking patterns (e.g., all X's) for better clarity.- "clientId": "95XXX171", - "clientSecret": "234X2565", - "subDomain": "SubDomain*******************" + "clientId": "XXXXXXXX", + "clientSecret": "XXXXXXXX", + "subDomain": "XXXXXXXXXXXXXXXXXXXXXXXXXXXX"
1-19
: Enhance test coverage with additional validation scenarios.Current test cases only cover valid configuration and invalid subDomain. Consider adding test cases for:
- Invalid clientId pattern
- Invalid clientSecret pattern
- Missing required fields
- Consent management configurations
Would you like me to generate additional test cases to improve coverage?
src/configurations/destinations/sfmc_v2/ui-config.json (1)
19-20
: Document regex patterns for maintainability.The validation patterns for
clientId
,clientSecret
, andsubDomain
are complex. Consider adding comments explaining the pattern requirements:"configKey": "clientId", + "// Pattern allows: environment variables (env.*), template variables ({{.*||.*}}), or 1-100 characters", "regex": "(^\\{\\{.*\\|\\|(.*)\\}\\}$)|(^env[.].+)|^(.{1,100})$",
Also applies to: 27-28, 35-36
src/configurations/destinations/sfmc_v2/schema.json (1)
19-154
: Consider using schema reuse for platform-specific configurations.The
oneTrustCookieCategories
object repeats the same structure for multiple platforms. Consider using schema references to reduce duplication:{ "configSchema": { "definitions": { + "cookieCategoryArray": { + "type": "array", + "items": { + "type": "object", + "properties": { + "oneTrustCookieCategory": { + "type": "string", + "pattern": "(^\\{\\{.*\\|\\|(.*)\\}\\}$)|(^env[.].+)|^(.{0,100})$" + } + } + } + } }, "properties": { "oneTrustCookieCategories": { "type": "object", "properties": { - "android": { - "type": "array", - "items": { - "type": "object", - "properties": { - "oneTrustCookieCategory": { - "type": "string", - "pattern": "(^\\{\\{.*\\|\\|(.*)\\}\\}$)|(^env[.].+)|^(.{0,100})$" - } - } - } - }, + "android": { "$ref": "#/definitions/cookieCategoryArray" }, // Apply similar changes for other platforms } } } } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
src/configurations/destinations/sfmc_v2/db-config.json
(1 hunks)src/configurations/destinations/sfmc_v2/schema.json
(1 hunks)src/configurations/destinations/sfmc_v2/ui-config.json
(1 hunks)test/data/validation/destinations/sfmc_v2.json
(1 hunks)
🔇 Additional comments (3)
src/configurations/destinations/sfmc_v2/db-config.json (1)
1-34
: LGTM! Configuration structure is well-defined.The configuration includes all necessary components:
- CDK v2 enabled
- Proper source and message type restrictions
- Comprehensive consent management settings
- Beta status with feature flag
src/configurations/destinations/sfmc_v2/ui-config.json (1)
66-136
: LGTM! Well-structured consent management UI.The consent management configuration provides:
- Clear provider selection
- Logical resolution strategy options
- Comprehensive consent category handling
src/configurations/destinations/sfmc_v2/schema.json (1)
293-803
: LGTM! Comprehensive consent management schema.The schema properly validates:
- Provider selection with enumerated values
- Resolution strategy requirements
- Consent configuration patterns
What are the changes introduced in this PR?
We are onboarding sfmc_v2 destination.
What is the related Linear task?
Resolves INT-3136
Please explain the objectives of your changes below
Put down any required details on the broader aspect of your changes. If there are any dependent changes, mandatorily mention them here
Any changes to existing capabilities/behaviour, mention the reason & what are the changes ?
N/A
Any new dependencies introduced with this change?
N/A
Any new checks got introduced or modified in test suites. Please explain the changes.
N/A
Developer checklist
My code follows the style guidelines of this project
No breaking changes are being introduced.
All related docs linked with the PR?
All changes manually tested?
Any documentation changes needed with this change?
I have executed schemaGenerator tests and updated schema if needed
Are sensitive fields marked as secret in definition config?
My test cases and placeholders use only masked/sample values for sensitive fields
Is the PR limited to 10 file changes & one task?
Reviewer checklist
Is the type of change in the PR title appropriate as per the changes?
Verified that there are no credentials or confidential data exposed with the changes.
Summary by CodeRabbit
New Features
Tests
Documentation