My_Egeria pull request - #346
Merged
Merged
Conversation
…included in auto tests or added to documentation Signed-off-by: Peter Coldicott <86156876+pcoldico@users.noreply.github.com>
Signed-off-by: Peter Coldicott <86156876+pcoldico@users.noreply.github.com>
…eturn codes across the application Signed-off-by: Peter Coldicott <86156876+pcoldico@users.noreply.github.com>
…rt-spec review batch) (odpi#342) * docs(PYEGERIA_ISSUES): ISSUE-87/86/80 fixed, ISSUE-88 corrected as not-a-bug ISSUE-88: not a bug. GovernanceZone (0424) is a GovernanceDefinition subtype like every other one create_governance_definition already handles -- pass GovernanceDefinitionProperties with typeName: "GovernanceZone" (same generic mechanism as BusinessImperative/RegulationArticle/etc.). Confirmed against GOV_DEF_PROPERTIES_LIST (pyegeria/omvs/governance_officer.py) and the .http ground truth, which has no separate governance-zones create endpoint at all. Moved to the 'Not a bug / n/a' section; kept the original report for history. Real, separate follow-up noted: the method's own docstring doesn't list GovernanceZone (or other 0401-family subtypes) as valid typeName values -- a documentation gap, not an API gap. ISSUE-87, ISSUE-80, ISSUE-86: entries updated to record the fixes landed in this same session (see the corresponding code commits) -- docstring correction, MCP tool exposure, and bearer-token support in exec_report_spec, respectively. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * fix(classification-explorer): ISSUE-87 -- correct OwnerProperties -> OwnershipProperties in add_ownership_to_element docstrings _async_add_ownership_to_element/add_ownership_to_element documented a sample body with "class": "OwnerProperties", but the method itself validates against prop=["OwnershipProperties"] -- the documented body was rejected client-side (PyegeriaInvalidParameterException, 'unexpected property class name') before any HTTP call, 100% of the time. .http ground truth already used OwnershipProperties and agreed with the code; the docstring was the outlier, repeated in both the async and sync wrapper. Fix: both docstrings corrected to OwnershipProperties. Swept every other _async_new_classification_request caller in the file (matched by function boundary, not naive line-proximity, to avoid false positives from adjacent functions) -- this was the only class-name/ prop= mismatch in classification_explorer.py. Verified: TypeAdapter(NewClassificationRequestBody).validate_python(...) with the corrected body now validates cleanly (previously raised ValidationError). Full pytest tests/micro-tests/ green. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * feat(format-set-executor): ISSUE-86 -- exec_report_spec accepts a bearer token, not just user/user_pass exec_report_spec (and its two client-building helpers, _exec_analytic_chart and _run_analytic_function) always built a fresh EgeriaTech/client from user/user_pass and called create_egeria_bearer_token() -- no way to run a report as a caller who already holds a bearer token for the calling user. Egeria Advisor's app JWT carries the user's Egeria bearer token and no longer their password (matching the Portal's existing X-Egeria-Token + set_bearer_token() pattern), so report execution had to fall back to a service account, and Egeria's provenance recorded that service account instead of the person who ran the report. Fix: added token: Optional[str] = None to exec_report_spec, _exec_analytic_chart, and _run_analytic_function, threaded through every client-building call site. When token is given, the client is authenticated with set_bearer_token(token) instead of create_egeria_bearer_token(); when omitted, behavior is byte-for-byte unchanged. NewElementRequestBody-style constructors already accept a token= kwarg directly (confirmed: EgeriaTech.__init__ and ServerClient .__init__ both do, and lazily-instantiated sub-clients inherit self.token via _get_subclient), so no model changes were needed. New test tests/micro-tests/test_exec_report_spec_token.py (2 tests, monkeypatched EgeriaTech, no live server): confirms token routes through set_bearer_token with zero calls to create_egeria_bearer_token, and confirms the no-token path is unchanged. Full pytest tests/micro-tests/ green. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * feat(mcp): ISSUE-80 -- expose find_report_specs_by_perspective/by_question as MCP tools; ISSUE-86 -- thread bearer token through run_report ISSUE-80: find_report_specs_by_perspective/find_report_specs_by_question (pyegeria/view/base_report_formats.py) were real, working, tested functions with no MCP tool or CLI command exposing them -- only their own functional test exercised them. Added run_find_report_specs_by_ perspective/run_find_report_specs_by_question adapters (same thin-wrapper pattern as the existing run_find_report_specs) and registered them as MCP tools find_report_specs_by_perspective/find_report_specs_by_question, alongside the existing find_report_specs tool. Pure additive wiring, no change to the underlying functions. hey_egeria CLI exposure (the issue's 'and/or' half) left undone -- MCP was the natural fit given the existing find_report_specs tool precedent. ISSUE-86: run_report and _execute_egeria_call_blocking (mcp_adapter.py) now accept token: Optional[str] = None and pass it through to exec_report_spec, so a caller that already holds a bearer token for the calling user can run a report as that user instead of the user/user_pass service account. describe_report doesn't build a client (pure registry lookup) so needed no change. mcp_server.py's own run_report MCP tool takes a different, already-token-capable path (a pre-built egeria_client passed to _async_run_report_tool, not exec_report_spec's builder) and is out of scope here. Full pytest tests/micro-tests/ green throughout. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> --------- Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
Bumps [actions/checkout](https://github.com/actions/checkout) from 4.4.0 to 7.0.1. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@11d5960...3d3c42e) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: 7.0.1 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
Bumps [click](https://github.com/pallets/click) from 8.3.1 to 8.5.0. - [Release notes](https://github.com/pallets/click/releases) - [Changelog](https://github.com/pallets/click/blob/main/CHANGES.md) - [Commits](pallets/click@8.3.1...8.5.0) --- updated-dependencies: - dependency-name: click dependency-version: 8.5.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
Bumps [altair](https://github.com/vega/altair) from 6.0.0 to 6.2.2. - [Release notes](https://github.com/vega/altair/releases) - [Commits](vega/altair@v6.0.0...v6.2.2) --- updated-dependencies: - dependency-name: altair dependency-version: 6.2.2 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
Bumps [astral-sh/setup-uv](https://github.com/astral-sh/setup-uv) from 3.2.4 to 10.0.1. - [Release notes](https://github.com/astral-sh/setup-uv/releases) - [Commits](astral-sh/setup-uv@caf0cab...20cfd1b) --- updated-dependencies: - dependency-name: astral-sh/setup-uv dependency-version: 10.0.1 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
Bumps [softprops/action-gh-release](https://github.com/softprops/action-gh-release) from 1 to 2. - [Release notes](https://github.com/softprops/action-gh-release/releases) - [Changelog](https://github.com/softprops/action-gh-release/blob/master/CHANGELOG.md) - [Commits](softprops/action-gh-release@de2c0eb...3bb1273) --- updated-dependencies: - dependency-name: softprops/action-gh-release dependency-version: '2' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
…pi#329) Bumps [github/codeql-action/init](https://github.com/github/codeql-action) from 3.37.9 to 4.37.9. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@6f5948d...cdf488f) --- updated-dependencies: - dependency-name: github/codeql-action/init dependency-version: 4.37.9 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
…dpi#331) Bumps [github/codeql-action/analyze](https://github.com/github/codeql-action) from 3.37.9 to 4.37.9. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@6f5948d...cdf488f) --- updated-dependencies: - dependency-name: github/codeql-action/analyze dependency-version: 4.37.9 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
First tagged/CI-built release since 6.1.8 (6.1.9 was an out-of-band publish, never tagged). Includes: click 8.3.1->8.5.0, altair 6.0.0->6.2.2, actions/checkout/setup-uv/codeql-action/action-gh-release CI bumps (odpi#325-odpi#331), and ISSUE-86/87/80 fixes (odpi#342). Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
* docs(PYEGERIA_ISSUES): log ISSUE-91 -- mcp dependency floor too loose pyproject.toml declares mcp >=0.1 but pyegeria/core/mcp_server.py imports mcp.server.mcpserver.MCPServer, which requires mcp>=2.0 (confirmed live: this dev venv has mcp==2.0.0 installed and the import works; the module path doesn't exist in the 0.x/1.x mcp package line). Found by Egeria Advisor rebuilding its demo deployment against pyegeria 6.1.10 -- worked fine because they pinned mcp==2.1.1 explicitly, not because pyegeria's own floor would have caught an older mcp. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * test(view): cover ISSUE-86's caller-held bearer token in exec_report_spec format_set_executor.py's `token` parameter (ISSUE-86 — let a caller that already holds an Egeria bearer token run a report without a password) is on main with no dedicated test. These tests existed only on an unpushed local branch, claude/cranky-chebyshev-be2494, alongside a second, parallel implementation of the same feature that main had meanwhile gained by another route. Pushing that branch would have added a duplicate implementation; the tests were the part worth keeping, so they are salvaged here on their own. They were written against that branch's `_authenticate_client()` helper, which main does not have — verified they pass unchanged against main's inline implementation (7 passed), so they test the behaviour rather than that refactor's shape. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> --------- Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
…alog-MyE report format Signed-off-by: Peter Coldicott <86156876+pcoldico@users.noreply.github.com>
…, previous commit was just the test code Signed-off-by: Peter Coldicott <86156876+pcoldico@users.noreply.github.com>
pcoldico
added a commit
to pcoldico/egeria-python
that referenced
this pull request
Sep 8, 2026
* End of day backup, added my bookmarks functionality, not yet tested, included in auto tests or added to documentation Signed-off-by: Peter Coldicott <86156876+pcoldico@users.noreply.github.com> * Save changes to enable my_bookmarks functionality Signed-off-by: Peter Coldicott <86156876+pcoldico@users.noreply.github.com> * Updates to the flows in Shop for Data and a new MD doc covering all return codes across the application Signed-off-by: Peter Coldicott <86156876+pcoldico@users.noreply.github.com> * fix+feat: ISSUE-87/80/86 fixed, ISSUE-88 corrected as not-a-bug (report-spec review batch) (odpi#342) * docs(PYEGERIA_ISSUES): ISSUE-87/86/80 fixed, ISSUE-88 corrected as not-a-bug ISSUE-88: not a bug. GovernanceZone (0424) is a GovernanceDefinition subtype like every other one create_governance_definition already handles -- pass GovernanceDefinitionProperties with typeName: "GovernanceZone" (same generic mechanism as BusinessImperative/RegulationArticle/etc.). Confirmed against GOV_DEF_PROPERTIES_LIST (pyegeria/omvs/governance_officer.py) and the .http ground truth, which has no separate governance-zones create endpoint at all. Moved to the 'Not a bug / n/a' section; kept the original report for history. Real, separate follow-up noted: the method's own docstring doesn't list GovernanceZone (or other 0401-family subtypes) as valid typeName values -- a documentation gap, not an API gap. ISSUE-87, ISSUE-80, ISSUE-86: entries updated to record the fixes landed in this same session (see the corresponding code commits) -- docstring correction, MCP tool exposure, and bearer-token support in exec_report_spec, respectively. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * fix(classification-explorer): ISSUE-87 -- correct OwnerProperties -> OwnershipProperties in add_ownership_to_element docstrings _async_add_ownership_to_element/add_ownership_to_element documented a sample body with "class": "OwnerProperties", but the method itself validates against prop=["OwnershipProperties"] -- the documented body was rejected client-side (PyegeriaInvalidParameterException, 'unexpected property class name') before any HTTP call, 100% of the time. .http ground truth already used OwnershipProperties and agreed with the code; the docstring was the outlier, repeated in both the async and sync wrapper. Fix: both docstrings corrected to OwnershipProperties. Swept every other _async_new_classification_request caller in the file (matched by function boundary, not naive line-proximity, to avoid false positives from adjacent functions) -- this was the only class-name/ prop= mismatch in classification_explorer.py. Verified: TypeAdapter(NewClassificationRequestBody).validate_python(...) with the corrected body now validates cleanly (previously raised ValidationError). Full pytest tests/micro-tests/ green. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * feat(format-set-executor): ISSUE-86 -- exec_report_spec accepts a bearer token, not just user/user_pass exec_report_spec (and its two client-building helpers, _exec_analytic_chart and _run_analytic_function) always built a fresh EgeriaTech/client from user/user_pass and called create_egeria_bearer_token() -- no way to run a report as a caller who already holds a bearer token for the calling user. Egeria Advisor's app JWT carries the user's Egeria bearer token and no longer their password (matching the Portal's existing X-Egeria-Token + set_bearer_token() pattern), so report execution had to fall back to a service account, and Egeria's provenance recorded that service account instead of the person who ran the report. Fix: added token: Optional[str] = None to exec_report_spec, _exec_analytic_chart, and _run_analytic_function, threaded through every client-building call site. When token is given, the client is authenticated with set_bearer_token(token) instead of create_egeria_bearer_token(); when omitted, behavior is byte-for-byte unchanged. NewElementRequestBody-style constructors already accept a token= kwarg directly (confirmed: EgeriaTech.__init__ and ServerClient .__init__ both do, and lazily-instantiated sub-clients inherit self.token via _get_subclient), so no model changes were needed. New test tests/micro-tests/test_exec_report_spec_token.py (2 tests, monkeypatched EgeriaTech, no live server): confirms token routes through set_bearer_token with zero calls to create_egeria_bearer_token, and confirms the no-token path is unchanged. Full pytest tests/micro-tests/ green. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * feat(mcp): ISSUE-80 -- expose find_report_specs_by_perspective/by_question as MCP tools; ISSUE-86 -- thread bearer token through run_report ISSUE-80: find_report_specs_by_perspective/find_report_specs_by_question (pyegeria/view/base_report_formats.py) were real, working, tested functions with no MCP tool or CLI command exposing them -- only their own functional test exercised them. Added run_find_report_specs_by_ perspective/run_find_report_specs_by_question adapters (same thin-wrapper pattern as the existing run_find_report_specs) and registered them as MCP tools find_report_specs_by_perspective/find_report_specs_by_question, alongside the existing find_report_specs tool. Pure additive wiring, no change to the underlying functions. hey_egeria CLI exposure (the issue's 'and/or' half) left undone -- MCP was the natural fit given the existing find_report_specs tool precedent. ISSUE-86: run_report and _execute_egeria_call_blocking (mcp_adapter.py) now accept token: Optional[str] = None and pass it through to exec_report_spec, so a caller that already holds a bearer token for the calling user can run a report as that user instead of the user/user_pass service account. describe_report doesn't build a client (pure registry lookup) so needed no change. mcp_server.py's own run_report MCP tool takes a different, already-token-capable path (a pre-built egeria_client passed to _async_run_report_tool, not exec_report_spec's builder) and is out of scope here. Full pytest tests/micro-tests/ green throughout. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> --------- Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * chore(deps): Bump actions/checkout from 4.4.0 to 7.0.1 (odpi#330) Bumps [actions/checkout](https://github.com/actions/checkout) from 4.4.0 to 7.0.1. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@11d5960...3d3c42e) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: 7.0.1 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * chore(deps): Bump click from 8.3.1 to 8.5.0 (odpi#328) Bumps [click](https://github.com/pallets/click) from 8.3.1 to 8.5.0. - [Release notes](https://github.com/pallets/click/releases) - [Changelog](https://github.com/pallets/click/blob/main/CHANGES.md) - [Commits](pallets/click@8.3.1...8.5.0) --- updated-dependencies: - dependency-name: click dependency-version: 8.5.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * chore(deps): Bump altair from 6.0.0 to 6.2.2 (odpi#327) Bumps [altair](https://github.com/vega/altair) from 6.0.0 to 6.2.2. - [Release notes](https://github.com/vega/altair/releases) - [Commits](vega/altair@v6.0.0...v6.2.2) --- updated-dependencies: - dependency-name: altair dependency-version: 6.2.2 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * chore(deps): Bump astral-sh/setup-uv from 3.2.4 to 10.0.1 (odpi#326) Bumps [astral-sh/setup-uv](https://github.com/astral-sh/setup-uv) from 3.2.4 to 10.0.1. - [Release notes](https://github.com/astral-sh/setup-uv/releases) - [Commits](astral-sh/setup-uv@caf0cab...20cfd1b) --- updated-dependencies: - dependency-name: astral-sh/setup-uv dependency-version: 10.0.1 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * chore(deps): Bump softprops/action-gh-release from 1 to 2 (odpi#325) Bumps [softprops/action-gh-release](https://github.com/softprops/action-gh-release) from 1 to 2. - [Release notes](https://github.com/softprops/action-gh-release/releases) - [Changelog](https://github.com/softprops/action-gh-release/blob/master/CHANGELOG.md) - [Commits](softprops/action-gh-release@de2c0eb...3bb1273) --- updated-dependencies: - dependency-name: softprops/action-gh-release dependency-version: '2' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * chore(deps): Bump github/codeql-action/init from 3.37.9 to 4.37.9 (odpi#329) Bumps [github/codeql-action/init](https://github.com/github/codeql-action) from 3.37.9 to 4.37.9. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@6f5948d...cdf488f) --- updated-dependencies: - dependency-name: github/codeql-action/init dependency-version: 4.37.9 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * chore(deps): Bump github/codeql-action/analyze from 3.37.9 to 4.37.9 (odpi#331) Bumps [github/codeql-action/analyze](https://github.com/github/codeql-action) from 3.37.9 to 4.37.9. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@6f5948d...cdf488f) --- updated-dependencies: - dependency-name: github/codeql-action/analyze dependency-version: 4.37.9 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * chore(release): bump version to 6.1.10 (odpi#343) First tagged/CI-built release since 6.1.8 (6.1.9 was an out-of-band publish, never tagged). Includes: click 8.3.1->8.5.0, altair 6.0.0->6.2.2, actions/checkout/setup-uv/codeql-action/action-gh-release CI bumps (odpi#325-odpi#331), and ISSUE-86/87/80 fixes (odpi#342). Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * Some small fixes (odpi#344) * docs(PYEGERIA_ISSUES): log ISSUE-91 -- mcp dependency floor too loose pyproject.toml declares mcp >=0.1 but pyegeria/core/mcp_server.py imports mcp.server.mcpserver.MCPServer, which requires mcp>=2.0 (confirmed live: this dev venv has mcp==2.0.0 installed and the import works; the module path doesn't exist in the 0.x/1.x mcp package line). Found by Egeria Advisor rebuilding its demo deployment against pyegeria 6.1.10 -- worked fine because they pinned mcp==2.1.1 explicitly, not because pyegeria's own floor would have caught an older mcp. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * test(view): cover ISSUE-86's caller-held bearer token in exec_report_spec format_set_executor.py's `token` parameter (ISSUE-86 — let a caller that already holds an Egeria bearer token run a report without a password) is on main with no dedicated test. These tests existed only on an unpushed local branch, claude/cranky-chebyshev-be2494, alongside a second, parallel implementation of the same feature that main had meanwhile gained by another route. Pushing that branch would have added a duplicate implementation; the tests were the part worth keeping, so they are salvaged here on their own. They were written against that branch's `_authenticate_client()` helper, which main does not have — verified they pass unchanged against main's inline implementation (7 passed), so they test the behaviour rather than that refactor's shape. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> --------- Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> * Update to base_report_formats to add the GUID to the Data-Product-Catalog-MyE report format Signed-off-by: Peter Coldicott <86156876+pcoldico@users.noreply.github.com> * Update to base_report_formats to add GUID to Data-Product-Catalog-MyE, previous commit was just the test code Signed-off-by: Peter Coldicott <86156876+pcoldico@users.noreply.github.com> --------- Signed-off-by: Peter Coldicott <86156876+pcoldico@users.noreply.github.com> Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: Dan Wolfson <dan.wolfson@pdr-associates.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2 tasks
dwolfson
added a commit
that referenced
this pull request
Sep 8, 2026
…on to 6.1.12 (#351) * ISSUE-93: declassify_metadata_element raises when its Optional body is omitted `MetadataExpert.declassify_metadata_element(guid, classification_name, body=None)` declares `body` as Optional but calls `.model_dump()` on it unconditionally, so omitting it raises `AttributeError: 'NoneType' object has no attribute 'model_dump'` and the classification is left in place. Worse than an ordinary signature bug because the failure is silent at the caller. A caller that wraps the call defensively — reasonable, since removing a classification that is already absent should not be fatal — swallows the AttributeError and believes the removal happened. Measured live: kinds before ['Task'], declassify raises, kinds after ['Task']. In our case the element then carried TWO kind classifications at once (['Task', 'PersonalProject']) and a check that only asked "is the new classification present?" reported success. The wrong-but-plausible state was invisible until the element was read back for BOTH names. Workaround verified: passing `{"class": "MetadataSourceRequestBody"}` explicitly makes it work (kinds after: []). Candidate fix is to default the body when None, matching the declaration. `classify_metadata_element` and `reclassify_metadata_element` sit beside it with the same Optional body declaration and are worth checking — we pass a body to both so we have not hit them. Logged, not fixed, per the standing rule for this repo. Found in trellis/packages/resource-explorer's investigation reclassifier, which now passes the body and additionally asserts the OLD classification is gone rather than only that the new one arrived. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * fix(tests): update stale shop_for_data catalog-search assertion; chore(release): bump version to 6.1.12 test_handle_shop_for_data_option_success asserted the Digital-Product-Catalog-MyE search call's params as {"search_string": "*"} only. PR #346 added a metadata_element_subtypes: ["DigitalProduct", "DigitalProductFamily"] filter to that call; the test was never updated to match, so it failed deterministically (not flaky) on every run since -- this is what blocked the v6.1.11 release workflow's PyPI publish step (build never ran; see release run 34252940497). Also bumps to 6.1.12: PyPI already had a 6.1.11 published at 2026-09-08T02:15 UTC, ~14.5h before this repo's v6.1.11 tag/PR merged, with different (older) content -- a pre-existing version collision unrelated to this fix. 6.1.12 is the first clean, unused version number. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KYNxABE3SRUT5cXbpmrfU2 Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> --------- Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Incorporate multiple commits, the most recent is an update to base_report_formats to add the catalogs GUID to the report Data-Product-Catalog-MyE