Add template context fields for Elastic integration

[brant-livefront]

📔 Objective

While building a POC integration to Elastic, I discovered that they want a specific timestamp date format (ISO 8601). In addition, I noticed that there were a very fields on our EventMessage object that I hadn't exposed on the IntegrationTemplateContext object. This PR adds these fields to the template context to allow them to be easily picked up in templates and specifically used as part of the Elastic integration.

⏰ 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

---

Code Review Complete ✓

Tasks

• Read the modified IntegrationTemplateContext.cs file
• Review the EventMessage class for context
• Check test file for coverage
• Analyze code quality and best practices
• Check security implications
• Verify test coverage requirements
• Provide comprehensive review feedback

---

Summary of Changes

This PR exposes 9 additional ID fields from EventMessage and adds a new DateIso8601 property to support Elastic's ISO 8601 timestamp requirements:

New ID Fields:

• IdempotencyId, ProviderId, ProviderUserId, ProviderOrganizationId
• InstallationId, SecretId, ProjectId, ServiceAccountId, GrantedServiceAccountId

New Formatted Property:

• DateIso8601 - Returns the Date in ISO 8601 format using .ToString("o")

---

Critical Issues

⚠️ Missing Unit Tests

According to the project's CLAUDE.md guidelines: "ALWAYS add unit tests (with mocking) for any new feature development"

The new DateIso8601 property lacks test coverage. While the new ID properties are simple pass-throughs (which may not require extensive testing), the DateIso8601 property performs a transformation and should have tests.

Recommended Test Cases

Add tests to IntegrationTemplateContextTests.cs:

[Theory, BitAutoData]
public void DateIso8601_ReturnsIso8601FormattedDate(EventMessage eventMessage)
{
    var testDate = new DateTime(2025, 10, 27, 13, 30, 0, DateTimeKind.Utc);
    eventMessage.Date = testDate;
    var sut = new IntegrationTemplateContext(eventMessage);
    
    var result = sut.DateIso8601;
    
    Assert.Equal("2025-10-27T13:30:00.0000000Z", result);
    // Verify it's valid ISO 8601
    Assert.True(DateTime.TryParse(result, out _));
}

[Theory, BitAutoData]
public void DateIso8601_HandlesLocalTime(EventMessage eventMessage)
{
    var localDate = new DateTime(2025, 10, 27, 13, 30, 0, DateTimeKind.Local);
    eventMessage.Date = localDate;
    var sut = new IntegrationTemplateContext(eventMessage);
    
    var result = sut.DateIso8601;
    
    // Verify format includes timezone offset
    Assert.Matches(@"\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}", result);
}

---

Suggested Improvements

🎨 Potential Timezone Consideration

The DateIso8601 property uses .ToString("o") which produces ISO 8601 format, but consider documenting whether the Date property is expected to be UTC or local time. Elastic typically prefers UTC timestamps.

Context

If Event.Date can contain local times, you may want to ensure UTC conversion:

public string DateIso8601 => Date.ToUniversalTime().ToString("o");

However, if Event.Date is always UTC (which is likely for event logs), the current implementation is fine. Just worth documenting this assumption.

📝 Minor: PR Title Typo

The PR title contains a typo: "Elasic" should be "Elastic"

---

Good Practices Observed

👍 Complete Field Coverage - All relevant ID fields from EventMessage are now exposed
👍 Consistent Naming - New properties follow existing naming conventions
👍 Read-Only Properties - Properly uses expression-bodied members for pass-through properties
👍 Existing Test Coverage - The codebase has a solid test suite for this class

---

Action Items

1. ❌ Required: Add unit tests for the DateIso8601 property (see examples above)
2. ℹ️ Optional: Consider adding XML documentation comments to explain the ISO 8601 format choice, especially if this is driven by Elastic's requirements
3. ℹ️ Optional: Verify timezone handling for DateIso8601 - confirm whether UTC conversion is needed
4. ⛏ Nitpick: Fix typo in PR title ("Elasic" → "Elastic")

---

Security & Performance Assessment

Security: ✅ No security concerns. The changes expose existing data fields without introducing new vulnerabilities. All exposed fields are GUIDs or formatted dates - no sensitive data leakage.

Performance: ✅ Minimal impact. The DateIso8601 property creates a new string on each access, but this is negligible for event logging scenarios. If performance becomes a concern in high-throughput scenarios, consider caching the formatted value.

---

Verdict

The implementation is clean and straightforward, but unit tests are required before merging per project guidelines. Once tests are added for DateIso8601, this PR will be ready to merge.

---

[github-actions]

Checkmarx One – Scan Summary & Details – 23bea6ed-2db9-440d-9ea6-26952ebda5ef

Great job! No new security vulnerabilities introduced in this pull request

[codecov]

Codecov Report

❌ Patch coverage is 0% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 52.02%. Comparing base (427600d) to head (c0fc805).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...ta/EventIntegrations/IntegrationTemplateContext.cs	0.00%	10 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6504      +/-   ##
==========================================
- Coverage   52.02%   52.02%   -0.01%     
==========================================
  Files        1878     1878              
  Lines       82706    82716      +10     
  Branches     7322     7322              
==========================================
  Hits        43030    43030              
- Misses      38018    38028      +10     
  Partials     1658     1658              

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

[withinfocus]

Some good Claude callouts for improvements but works for me at the moment.