Skip to content

docs(issues): ISSUE-158 correction; ISSUE-112 and ISSUE-117 pass on Egeria main #468

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
dwolfson merged 1 commit into from
Oct 20, 2026
Merged

docs(issues): ISSUE-158 correction; ISSUE-112 and ISSUE-117 pass on Egeria main #468

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion PYEGERIA_ISSUES.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -290,7 +290,7 @@ they're holding real port materialization until this exists server-side

**Layer:** Pyegeria · **Status:** open, not fixed (owner approval needed) · **Found:** 2026-10-19, raised by the TestGen evaluation session while drafting a DataQualityRule convenience-API spec (`~/localGit/egeria-v6/wt-testgen-notes/packages/resource-explorer/docs/design-notes/SPEC-PYEGERIA-DATA-QUALITY-RULE.md`, uncommitted, pending owner review). Both points confirmed in source here, read-only; not run live.

1. **Whitelist gap.** `GOV_DEF_PROPERTIES_LIST` (`pyegeria/omvs/governance_officer.py:37`) is the client-side property-class whitelist for `create_governance_definition` (`:426`) and `update_governance_definition` (`:955`). It has no `DataQualityRuleProperties`, although Egeria `main` has that class (`frameworks/.../properties/governance/DataQualityRuleProperties.java`). A caller-built DataQualityRule body is refused by pyegeria before it reaches the server. No Dr.Egeria command creates DataQualityRules today. **Proposed:** add `DataQualityRuleProperties`, and drop the list's duplicates (`RegulationProperties`, `GovernanceControlProperties` and `GovernanceApproachProperties` each appear twice). Better still, check the list against Egeria's `GovernanceDefinitionProperties` `@JsonSubTypes` so it can't drift again.
1. **Whitelist gap.** `GOV_DEF_PROPERTIES_LIST` (`pyegeria/omvs/governance_officer.py:37`) is the client-side property-class whitelist for `create_governance_definition` (`:426`) and `update_governance_definition` (`:955`). It has no `DataQualityRuleProperties`, although Egeria `main` has that class (`frameworks/.../properties/governance/DataQualityRuleProperties.java`). **Corrected 2026-10-19:** the list is enforced only on update. `validate_new_element_request` (`pyegeria/core/_server_client.py:6115`) has its class check commented out, so a create with `DataQualityRuleProperties` reaches Egeria unchanged. `validate_update_element_request` (`:6252`) does check a dict body's class against the list, so `update_governance_definition` refuses a DataQualityRule body client-side ("unexpected property class name"). No Dr.Egeria command creates DataQualityRules today. **Proposed:** add `DataQualityRuleProperties`, and drop the list's duplicates (`RegulationProperties`, `GovernanceControlProperties` and `GovernanceApproachProperties` each appear twice). Better still, check the list against Egeria's `GovernanceDefinitionProperties` `@JsonSubTypes` so it can't drift again.
2. **Silent fallback.** In `GovernanceProcessor`'s create path (`md_processing/v2/governance.py:203-221`), any non-SecurityGroup create that Egeria refuses with `OMAG-COMMON-400-029` (property class not accepted for `createGovernanceDefinition`) is retried with `_to_base_governance_definition_properties` (`:96`). That keeps only the cross-type fields (qualifiedName, displayName, description, category, identifier, contentStatus, versionIdentifier, effective dates, additional/extended properties). The element is created, but every type-specific attribute is dropped (e.g. a DataQualityRule's quality fields, a metric's `measurement`/`target`, a control's `implementationDescription`). The only sign is a `logger.warning`, and Dr.Egeria reports success. **Proposed:** remove the generic fallback, or keep it only for the server-compat case it was written for. Otherwise make it fail visibly, naming the dropped fields in the command's result. Live-test which current types, if any, still hit 400-029 on Egeria `main` before deciding.

---
Expand Down
Loading