Fix contactField permission validation to support isOwner condition

[Copilot]

Description

The isSupportedContactFieldCondition validation function rejected isOwner conditions despite SupportedContactFieldCondition type including ContactSpecificCondition. This caused contactField permission rules with owner-based logic to fail validation.

Changes

• Added isContactSpecificCondition(c) check to isSupportedContactFieldCondition validation function in rulesMap.ts

This aligns the runtime validation with the type definition, allowing contactField rules to use the same owner-based permission logic as contact rules.

const isSupportedContactFieldCondition = (c: any): c is SupportedContactFieldCondition =>
  isTimeBasedCondition(c) ||
  isUserBasedCondition(c) ||
  isContactSpecificCondition(c) ||  // Added
  isContactFieldSpecificCondition(c);

Checklist

• Corresponding issue has been opened
• New tests added
• Feature flags / configuration added

Other Related Issues

Part of stacked PR addressing feedback on #997

Verification steps

Unit tests verify the validation function accepts all types defined in SupportedContactFieldCondition:

cd hrm-domain/hrm-core
npx jest unit-tests/permissions/rulesMap.test.ts

AFTER YOU MERGE

1. Cut a release tag using the GitHub workflow. Wait for it to complete and notify in the #aselo-deploys Slack channel.
2. Comment on the ticket with the release tag version AND any additional instructions required to configure an environment to test the changes.
3. Only then move the ticket into the QA column in JIRA

You are responsible for ensuring the above steps are completed. If you move a ticket into QA without advising what version to test, the QA team will assume the latest tag has the changes. If it does not, the following confusion is on you! :-P

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.