Add template properties for Datadog

[brant-livefront]

📔 Objective

We recently got a few more specifics from the Datadog team on the existing pull-based integration. In order to support identical data being sent as part of our new push-based integration, we need a few more dynamic fields to enrich the data.

This PR adds these new dynamic fields.

⏰ Reminders before review

• Contributor guidelines followed
• All formatters and local linters executed and passed
• Written new unit and / or integration tests where applicable
• Protected functional changes with optionality (feature flags)
• Used internationalization (i18n) for all UI strings
• CI builds passed
• Communicated to DevOps any deployment requirements
• Updated any necessary documentation (Confluence, contributing docs) or informed the documentation team

🦮 Reviewer guidelines

• 👍 (:+1:) or similar for great changes
• 📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
• ❓ (:question:) for questions
• 🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion
• 🎨 (:art:) for suggestions / improvements
• ❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
• 🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
• ⛏ (:pick:) for minor or nitpick changes

[claude]

Claude finished @brant-livefront's task —— View job

---

PR Review Complete

Summary of Changes

This PR adds new dynamic template properties to support Datadog's push-based integration. The changes introduce UserType, ActingUserType, and GroupName properties to the IntegrationTemplateContext, along with supporting logic to fetch and populate these values.

Key Changes:

• Modified IntegrationTemplateContext to use OrganizationUserUserDetails instead of User entity
• Added UserType, ActingUserType, and GroupName template properties
• Updated EventIntegrationHandler to fetch organization user details and groups
• Added TemplateRequiresGroup() helper method
• Comprehensive unit test coverage for all new functionality

---

Critical Issues

1. ⚠️ Missing Null Check for OrganizationUser Lookup

File: src/Core/AdminConsole/Services/Implementations/EventIntegrations/EventIntegrationHandler.cs:106-110

var orgUser = await organizationUserRepository.GetByOrganizationAsync(organizationId: organizationId, userId: eventMessage.UserId.Value);
if (orgUser is not null)
{
    context.User = await organizationUserRepository.GetDetailsByIdAsync(orgUser.Id);
}

Issue: The code fetches OrganizationUser and then fetches details, but doesn't verify that GetDetailsByIdAsync returns a non-null value. If the user was deleted between the two calls, this could result in unexpected null values in the template context.

Recommendation: While this is a rare race condition, consider adding a null check or documenting this behavior. The same pattern exists for ActingUser (lines 113-120).

2. ⚠️ Potential N+1 Query Issue

File: src/Core/AdminConsole/Services/Implementations/EventIntegrations/EventIntegrationHandler.cs:90-128

Issue: The BuildContextAsync method makes separate repository calls for each template requirement:

• Group lookup (if needed)
• User org user lookup + details (if needed)
• ActingUser org user lookup + details (if needed)
• Organization lookup (if needed)

For events with multiple configurations or batch processing via HandleManyEventsAsync, this creates a potential N+1 query problem. Each event message triggers up to 6 separate database queries.

Recommendation: Consider implementing a caching strategy or batch loading mechanism, especially since:

1. Multiple configurations might use the same template
2. HandleManyEventsAsync processes events sequentially
3. The same users/groups/organizations may appear across multiple events

---

Suggested Improvements

3. 🎨 Inconsistent Error Handling for Repository Failures

File: src/Core/AdminConsole/Services/Implementations/EventIntegrations/EventIntegrationHandler.cs:94-96

The code has different error handling approaches:

• Group lookup: No try-catch, will bubble up exceptions
• User/ActingUser lookups: No try-catch, will bubble up exceptions
• Organization lookup: No try-catch, will bubble up exceptions

However, the outer HandleEventAsync (lines 38-78) has a try-catch that logs and continues on exception.

Recommendation: Consider whether repository failures during BuildContextAsync should:

1. Fail the entire event processing (current behavior via outer catch)
2. Partially populate the context with available data
3. Log specific warnings about missing data

Document the intended behavior for clarity.

4. 🎨 Template Token Validation Could Be More Efficient

File: src/Core/AdminConsole/Utilities/IntegrationTemplateProcessor.cs:33-75

The template checking methods (TemplateRequiresUser, TemplateRequiresActingUser, TemplateRequiresGroup, TemplateRequiresOrganization) each perform string contains checks individually. For templates with many tokens, this results in multiple passes over the template string.

Recommendation: Consider:

1. A single method that returns a struct/flags indicating all required entities
2. Caching the results if the same template is used across multiple configurations
3. Pre-computing requirements when configurations are loaded

This is a minor optimization but could improve performance for high-volume event processing.

5. 🎨 Missing XML Documentation

Files: Multiple

The new public properties on IntegrationTemplateContext and the new TemplateRequiresGroup method lack XML documentation comments.

Recommendation: Add XML docs consistent with the project's standards, especially for:

• IntegrationTemplateContext.UserType
• IntegrationTemplateContext.ActingUserType
• IntegrationTemplateContext.Group
• IntegrationTemplateContext.GroupName
• IntegrationTemplateProcessor.TemplateRequiresGroup()

6. 📝 Consider Adding Integration Tests

Testing Gap: While unit tests are comprehensive (excellent coverage!), there are no integration tests that verify:

1. The complete flow from event message → template rendering → published message
2. Database queries actually return the expected organization user details
3. Template rendering with real entity data

Recommendation: Consider adding integration tests in a future PR to validate the end-to-end behavior, especially the OrganizationUserRepository interactions which differ from the previous UserRepository approach.

7. 🎨 Code Style: Redundant Null Check

File: src/Core/AdminConsole/Utilities/IntegrationTemplateProcessor.cs:24-27

if (property == null)
{
    return match.Value;  // Return unknown keys as keys - i.e. #Key#
}

return property.GetValue(values)?.ToString() ?? string.Empty;

The null-coalescing operator on line 29 handles the null case for property.GetValue(), but the explicit null check for property on line 24 is good defensive coding. However, it could be simplified:

return property?.GetValue(values)?.ToString() ?? match.Value;

This would return the original token if the property doesn't exist, or use the value if it does (or empty string if value is null).

---

Good Practices Observed

• ✅ Comprehensive unit test coverage with proper mocking
• ✅ Consistent null-safety patterns with nullable reference types
• ✅ Use of StringComparison.Ordinal for performance
• ✅ Immutable context properties (get-only)
• ✅ Proper use of dependency injection pattern updates
• ✅ Test naming follows clear conventions

---

Security Considerations

✅ Zero-Knowledge Principles: No sensitive vault data is exposed in templates
✅ PII Handling: User email and name are appropriate for admin audit/integration contexts
✅ Injection Risks: Template system uses property reflection, not evaluation, minimizing injection risks
✅ Authorization: Changes operate within existing event integration authorization boundaries

No security concerns identified.

---

Performance Considerations

⚠️ Database Queries: As noted in issue #2, the N+1 query pattern could impact performance under high event volumes. Monitor database query counts in production.

💡 Recommendation: Consider implementing request-scoped caching for repository lookups within event batch processing.

---

Action Items for Author

1. Review N+1 Query Pattern: Consider adding caching or batch loading for repository calls, especially in HandleManyEventsAsync scenarios
2. Document Repository Failure Behavior: Clarify intended behavior when repository lookups fail during context building
3. Optional: Add XML documentation for new public APIs
4. Optional: Consider integration test coverage for the organization user lookup flow

---

Test Coverage Analysis

Current Coverage: 83.33% for new code (7 lines missing coverage per Codecov)

Missing Coverage Location: ServiceCollectionExtensions.cs:896-907 and EventIntegrationHandler.cs:91-128

The missing lines are in dependency injection setup code and the private BuildContextAsync method. Given the comprehensive unit test coverage of the actual logic, this is acceptable. The DI setup code is tested implicitly through integration tests.

---

Conclusion

This is a well-implemented feature with excellent test coverage. The main concerns are around potential performance implications of the N+1 query pattern and some minor refinements around error handling documentation. The code follows Bitwarden's architectural patterns and maintains security principles.

Recommendation: ✅ Approve with minor suggestions for follow-up improvements.

[github-actions]

Checkmarx One – Scan Summary & Details – 7fd9c589-872e-4584-8e2d-86ef9b1850c8

New Issues (1)

Checkmarx found the following issues in this Pull Request

Severity	Issue	Source File / Package	Checkmarx Insight
	CSRF	/src/Api/Billing/Controllers/VNext/AccountBillingVNextController.cs: 72	details Method at line 72 of /src/Api/Billing/Controllers/VNext/AccountBillingVNextController.cs gets a parameter from a user request from user. This pa... ID: ZWiNUnwMpO2ystke8b8neSGcojU%3D Attack Vector

[codecov]

Codecov Report

❌ Patch coverage is 83.33333% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 52.36%. Comparing base (ef665ba) to head (6938859).

Files with missing lines	Patch %	Lines
...SharedWeb/Utilities/ServiceCollectionExtensions.cs	0.00%	4 Missing ⚠️
...tions/EventIntegrations/EventIntegrationHandler.cs	85.71%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@                    Coverage Diff                    @@
##           brant/unit-test-coverage    #6528   +/-   ##
=========================================================
  Coverage                     52.35%   52.36%           
=========================================================
  Files                          1909     1909           
  Lines                         84640    84670   +30     
  Branches                       7561     7569    +8     
=========================================================
+ Hits                          44312    44335   +23     
- Misses                        38625    38631    +6     
- Partials                       1703     1704    +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[eliykat]

I assume my review is not required because this is merging into a feature branch (so codeowner requirements don't apply) and Architecture Team are handling this work. Please re-request my review if this is not the case.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
2.1% Duplication on New Code

See analysis details on SonarQube Cloud