fix: align Host Content Type behavior in New Edit Mode with Old Edit Mode

[oidacra]

Summary

Closes #34724

• Routes edit-host and create-host custom events through the feature-flag-aware editor selection logic, matching how edit-contentlet and create-contentlet already work
• When New Edit Mode is enabled for the Host content type, Sites Portlet entry points (Add Site, Click site, Right-click → Edit) now open the new Angular editor instead of always falling back to the legacy editor
• When the flag is NOT enabled, behavior remains unchanged (legacy editor)

Changes

dot-custom-event-handler.service.ts — Replaced hardcoded legacy editor bindings for edit-host and create-host with conditional bindings that check the contentEditorFeatureFlag, identical to the pattern used for edit-contentlet/create-contentlet.

dot-custom-event-handler.service.spec.ts — Added 6 test cases covering:

• edit-host → new editor (catchall + limited content types)
• create-host → new editor (catchall + limited content types)
• edit-host → legacy fallback when metadata flag disabled
• create-host → legacy fallback when metadata flag disabled

Test plan

• Enable New Edit Mode for Host content type via feature flag
• Sites Portlet → Add Site → Start with blank site → verify new editor opens
• Sites Portlet → Click on any site → verify new editor opens
• Sites Portlet → Right-click → Edit → verify new editor opens
• Disable New Edit Mode → verify all three entry points open the legacy editor
• All 1966 unit tests pass, 0 lint errors

[claude]

Claude finished @oidacra's task —— View job

---

PR Review Complete

Analysis Summary:

Reviewed the changes to align Host Content Type behavior between New and Old Edit Mode. Found one potential issue that should be addressed:

Issues Found:

⚠️ Potential Type Safety Issue in dot-custom-event-handler.service.ts:83-88:

'edit-host': contentEditorFeatureFlag
    ? this.editContentlet.bind(this)
    : this.editContentletLegacy.bind(this),
'create-host': contentEditorFeatureFlag
    ? this.createContentlet.bind(this)
    : this.createContentletLegacy.bind(this)

Problem: The editContentlet and createContentlet methods expect event data to include a contentType field ($event.detail.data.contentType), but host events from the Sites Portlet may not always provide this field in the expected format.

Risk: If host events don't include the contentType field, this could cause:

• dotContentTypeService.getContentType(undefined) calls
• Runtime errors in the conditional logic
• Fallback to legacy editor even when new editor should be used

Recommendation: Add defensive checks in the editContentlet/createContentlet methods to handle missing contentType fields, or ensure host events always include the contentType: 'Host' field.

Test Coverage:

✅ New test cases properly cover both feature flag enabled/disabled scenarios for both edit-host and create-host events
✅ Tests validate routing to new editor vs legacy fallback
✅ Test setup correctly mocks the content type metadata flags

Code Quality:

✅ Changes follow established patterns used for edit-contentlet/create-contentlet
✅ Conditional logic is consistent and readable
✅ No security concerns identified

Edge Cases to Consider:

• Host events without contentType field (mentioned above)
• Host content type with mixed metadata flag settings
• Race conditions during feature flag initialization

Overall: Clean implementation following established patterns, but verify host event data structure to prevent potential runtime issues.

[claude]

Claude finished @oidacra's task —— View job

---

PR Review Complete

• Read and analyze the changed files
• Check for issues, edge cases, and risks
• Review test coverage adequacy
• Provide final review feedback

Issues Found:

⚠️ Logic Error in Handler Binding in dot-custom-event-handler.service.ts:83-88:

'edit-host': contentEditorFeatureFlag
    ? this.editHost.bind(this)      // ❌ Should be this.editContentlet.bind(this) 
    : this.editContentletLegacy.bind(this),
'create-host': contentEditorFeatureFlag
    ? this.createHost.bind(this)    // ❌ Should be this.createContentlet.bind(this)
    : this.createContentletLegacy.bind(this)

Problem: The code binds to dedicated editHost/createHost methods instead of the generic editContentlet/createContentlet methods, but these new methods hardcode 'Host' as the content type instead of reading it from the event data.

Risk: This creates inconsistent behavior:

• edit-contentlet reads contentType from event: $event.detail.data.contentType
• edit-host ignores event data, hardcodes 'Host'

Other Issues:

• The new editHost/createHost methods duplicate logic that already exists in editContentlet/createContentlet
• Code violates DRY principle - same routing logic implemented twice

Recommendation: Remove the dedicated editHost/createHost methods and bind directly to editContentlet/createContentlet like the comment in the PR description suggests. The generic methods can handle Host content types if the event data includes contentType: 'Host'.

Test Coverage:

✅ Tests adequately cover both feature flag scenarios
✅ Tests validate routing to new vs legacy editor
❌ Tests don't verify the actual content type being fetched - they mock the service response

Edge Cases:

• Host events without contentType field in event data
• Race conditions during feature flag initialization
• Mixed metadata flag settings for Host content type

Verdict: The implementation doesn't match the PR description. The code should use the existing generic methods rather than creating Host-specific duplicates.

[claude]

Claude finished @oidacra's task —— View job

---

PR Review Complete

• Read and analyze the changed files
• Check for issues, edge cases, and risks
• Review test coverage adequacy
• Provide final review feedback

Issues Found:

⚠️ Logic Error in Handler Binding in dot-custom-event-handler.service.ts:83-88:

'edit-host': contentEditorFeatureFlag
    ? this.editHost.bind(this)      // ❌ Should be this.editContentlet.bind(this) 
    : this.editContentletLegacy.bind(this),
'create-host': contentEditorFeatureFlag
    ? this.createHost.bind(this)    // ❌ Should be this.createContentlet.bind(this)
    : this.createContentletLegacy.bind(this)

Problem: The code binds to dedicated editHost/createHost methods instead of the generic editContentlet/createContentlet methods, but these new methods hardcode 'Host' as the content type instead of reading it from the event data.

Risk: This creates inconsistent behavior:

• edit-contentlet reads contentType from event: $event.detail.data.contentType
• edit-host ignores event data, hardcodes 'Host'

Other Issues:

• The new editHost/createHost methods duplicate logic that already exists in editContentlet/createContentlet
• Code violates DRY principle - same routing logic implemented twice

Recommendation: Remove the dedicated editHost/createHost methods and bind directly to editContentlet/createContentlet like the comment in the PR description suggests. The generic methods can handle Host content types if the event data includes contentType: 'Host'.

Test Coverage:

✅ Tests adequately cover both feature flag scenarios
✅ Tests validate routing to new vs legacy editor
❌ Tests don't verify the actual content type being fetched - they mock the service response

Edge Cases:

• Host events without contentType field in event data
• Race conditions during feature flag initialization
• Mixed metadata flag settings for Host content type

Verdict: The implementation doesn't match the PR description. The code should use the existing generic methods rather than creating Host-specific duplicates.

---