Enable "Updated By, Synonyms,RelatedTerms,Status" field in workflow check conditions

[Copilot]

Describe your changes:

The "Updated By" field was only available in workflow check conditions for glossary terms. Users creating workflows for test suites and other entities could only access "Updated On" but not "Updated By".

Changes:

• Frontend (JSONLogicSearch.constants.ts): Moved UPDATED_BY from GLOSSARY_ENTITY_FIELDS_KEYS to COMMON_ENTITY_FIELDS_KEYS

Result: "Updated By" field with isOwner and isReviewer operators now available for all entity types in workflow conditions.

Example usage for test suites:

{
  "type": "checkEntityAttributesTask",
  "name": "CheckIfUpdatedByOwner",
  "config": {
    "rules": "{\"and\":[{\"isOwner\":{\"var\":\"updatedBy\"}}]}"
  }
}

---

Summary by Gitar

• New common entity fields:
  • Added ENTITY_STATUS to COMMON_ENTITY_FIELDS_KEYS for status-based filtering (Active/Deprecated/Deleted) in workflow conditions across all entity types
• New glossary entity fields:
  • Added SYNONYMS and RELATED_TERMS to GLOSSARY_ENTITY_FIELDS_KEYS for glossary-specific workflow conditions
• Field implementations:
  • ENTITY_STATUS: Select dropdown with status values and search capability
  • SYNONYMS: Multiselect with custom values support
  • RELATED_TERMS: Glossary term search with entity reference selection

_{This will update automatically on new commits.}

---

Type of change:

• Improvement

Checklist:

• I have read the CONTRIBUTING document.
• My PR title is Fixes <issue-number>: <short explanation>
• I have commented on my code, particularly in hard-to-understand areas.
• For JSON Schema changes: I updated the migration scripts or explained why it is not needed.

• I have added tests around the new logic.
• For connector/ingestion changes: I updated the documentation.

Original prompt

Is it possible to create a workflow with a check on the "Updated by" field for test suites? I'm only seeing "updated on" as an option -> is this a feature or was there a reason this was not added.

The customer is looking for this in the "Check Condition" where "Start Node Configuration" = TestSuite. They are able to find "Updated On"

We should have "Updated by" for json logics to be available for all, currently it is specific to glossary term.

---

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

[karanh37]

@copilot revert this change eventBasedEntityTrigger.json

[Copilot]

@copilot revert this change eventBasedEntityTrigger.json

Reverted in commit 6c37af9. The eventBasedEntityTrigger.json file now has maxItems: 1 as it was originally.

[github-actions]

Jest test Coverage

UI tests summary

Lines	Statements	Branches	Functions
	65.9% (55875/84789)	44.98% (28849/64143)	47.93% (8812/18385)

[gitar-bot]

⚠️ Bug: EntityStatus from glossary model used for all entity types

EntityStatus is imported from '../generated/entity/data/glossaryTerm' and used in the ENTITY_STATUS field definition. However, ENTITY_STATUS was added to COMMON_ENTITY_FIELDS_KEYS, meaning it will appear as an available field for all entity types (tables, test suites, etc.), not just glossary terms.

If EntityStatus values (e.g., "Approved", "Draft", etc.) are specific to glossary terms, showing them for entities like test suites or tables would be misleading — users would select a status value that doesn't exist on those entities, producing incorrect workflow conditions.

Suggested fix: Either:

1. Move ENTITY_STATUS from COMMON_ENTITY_FIELDS_KEYS to GLOSSARY_ENTITY_FIELDS_KEYS if the status field is glossary-specific, or
2. Verify that all entity types share the same EntityStatus values and document this assumption with a comment.

_{Was this helpful? React with 👍 / 👎}

[gitar-bot]

Code Review ⚠️ Changes requested 0 resolved / 2 findings

The core change (moving UPDATED_BY to common fields) is correct. However, ENTITY_STATUS uses glossary-specific EntityStatus values but is added to common fields for all entity types, which may show irrelevant options for non-glossary entities. The hardcoded "Related Terms" string from the previous review remains unaddressed.

⚠️ Bug: EntityStatus from glossary model used for all entity types

📄 openmetadata-ui/src/main/resources/ui/src/constants/JSONLogicSearch.constants.ts:40 📄 openmetadata-ui/src/main/resources/ui/src/utils/JSONLogicSearchClassBase.ts:40 📄 openmetadata-ui/src/main/resources/ui/src/utils/JSONLogicSearchClassBase.ts:417-431

EntityStatus is imported from '../generated/entity/data/glossaryTerm' and used in the ENTITY_STATUS field definition. However, ENTITY_STATUS was added to COMMON_ENTITY_FIELDS_KEYS, meaning it will appear as an available field for all entity types (tables, test suites, etc.), not just glossary terms.

If EntityStatus values (e.g., "Approved", "Draft", etc.) are specific to glossary terms, showing them for entities like test suites or tables would be misleading — users would select a status value that doesn't exist on those entities, producing incorrect workflow conditions.

Suggested fix: Either:

1. Move ENTITY_STATUS from COMMON_ENTITY_FIELDS_KEYS to GLOSSARY_ENTITY_FIELDS_KEYS if the status field is glossary-specific, or
2. Verify that all entity types share the same EntityStatus values and document this assumption with a comment.

💡 Quality: Hardcoded string instead of i18n translation function

📄 openmetadata-ui/src/main/resources/ui/src/utils/JSONLogicSearchClassBase.ts:460

The RELATED_TERMS subfield uses a hardcoded string 'Related Terms' for the label, while the parent field correctly uses the translation function t('label.related-term-plural'). This inconsistency could cause issues in non-English locales.

Suggested fix:

[EntityFields.FULLY_QUALIFIED_NAME]: {
  label: t('label.related-term-plural'), // or appropriate translation key
  type: 'select',
  ...
}

This ensures consistent internationalization throughout the codebase.

Rules 🎸 1 action taken

Gitar Rules

🎸 Flaky Test Retry: Retried 2 failed playwright jobs (3/6, 6/6) - both exhibited flaky test patterns unrelated to PR changes

_{2 rules not applicable. Show all rules by commenting gitar display:verbose.}

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqubecloud]

Quality Gate passed for 'open-metadata-ui'

Issues
5 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud