feat(dr-egeria): Reference Data authoring + Valid Metadata family; fix ISSUE-142

PYEGERIA_ISSUES.md

@@ -1405,6 +1405,35 @@ Sorted newest-first by `ISSUE-#` (2026-10-12). ISSUE-91 has two entries
 
 ---
 
+### ISSUE-142: Every Egeria error with relatedHTTPCode 401/403 was raised as "User not authorized", including 403 errors that are not about authorization
+
+**Layer:** Pyegeria · **Status:** fixed 2026-10-13 · **Found:** 2026-10-13, reported by the egeria-workspaces-fs Resource Browser session during a live work-list test.
+
+**What:** `CollectionManager.delete_collection` on a WorkingSet that still had
+members (cascade off) failed with Egeria's
+`OMAG-GENERIC-HANDLERS-403-005` -- an `InvalidParameterException` saying the
+element still has a dependent. Egeria wraps it with `relatedHTTPCode` 403.
+pyegeria's `_async_make_request` (`pyegeria/core/_base_server_client.py`)
+mapped any wrapped 401 or 403 to `PyegeriaUnauthorizedException` without
+looking at `exceptionClassName`, so the caller saw
+"AUTHORIZATION_ERROR_401 User not authorized received for user - ``". The
+real cause was hidden, the caller looked unauthenticated, and the user name
+was blank, because the exception was built with the JSON response as
+`additional_info`, which has no `userid`.
+
+**Fix:** a wrapped 401/403 is raised as `PyegeriaUnauthorizedException` only
+when `exceptionClassName` is `UserNotAuthorizedException`, or when it is a 401
+with no exception class. Any other 403 is raised as `PyegeriaAPIException`,
+carrying Egeria's own message. The user id is now passed, so the message names
+the user. Test: `tests/micro-tests/test_issue_142_403_not_always_unauthorized.py`.
+
+**Also checked, not affected:** in 6.2, `CollectionMembershipProperties`
+takes `confidence`; `expectedConfidence` is silently dropped. pyegeria already
+sends `confidence` (`collection_manager.py`,
+`md_processing/v2/collection_manager_processor.py`).
+
+---
+
 ### ISSUE-141: `ActionParameter.function` is a required string, so analytic-only specs must pass `""`, and the Advisor's validator then warns "No Action Function"
 
 **Layer:** pyegeria (report spec models) · **Status:** fixed 2026-10-12 on branch `docs/issue-136` (PR pending), not yet released · **Found:** 2026-10-12, reported by the Resource Explorer PR/CI session from trellis-analytics (trellis PR #622, `trellis_analytics/portal.py`), which works around it today.

commands/tech/spec_editor_static/app.js

@@ -1,7 +1,7 @@
 // Dr.Egeria Spec Editor -- vanilla JS, no build step, no framework.
 
 const STYLE_OPTIONS = [
-  "Simple", "Simple Int", "Simple Float", "Simple List", "Bool", "Enum",
+  "Simple", "Simple Int", "Simple Float", "Simple List", "Line List", "Table", "Bool", "Enum",
   "Valid Value", "QN", "GUID", "Reference Name", "Reference Name List",
   "Dictionary", "Named DICT",
 ];

docs/dr_egeria_manual.md

@@ -279,7 +279,8 @@ Dr.Egeria organizes its commands into "families," each corresponding to a specif
 
 - **Feedback**: Add comments, ratings, and informal tags to any Egeria element (e.g., `Add Comment`, `Attach Tag`). Also includes several `Person Action Base` commands (shared with Curation's `Create Meeting`/`Create ToDo` — see above): `Create Review`, implemented via `my_profile.create_review`; `Create Note`, which attaches an opinion/annotation about *any* target element (`Commented On Element`) via a dedicated `NoteLog`, typed as Egeria's real `Note` entity (a `Notification` subtype, added Egeria PR #9191, confirmed live 2026-08-04); and `Create Journal Entry`/`Create Activity Entry`/`Create Blog Entry`, three sibling commands for the calling user's own activity stream — private (`JournalEntry`), or public (`ActivityEntry`/`BlogEntry`) — implemented via `my_profile.journal_my_activity`/`log_my_activity`/`blog_my_activity` respectively. `Note`/`JournalEntry`/`ActivityEntry`/`BlogEntry` are all `Notification` subtypes attached through the same `NoteLog`/`AttachedNoteLogEntry` mechanism (see [egeria-project.org/concepts/notification](https://egeria-project.org/concepts/notification/)), differing only in target (any element vs. the user's own profile) and visibility.
 - **External Reference**: Link Egeria elements to external resources, media, or cited documents (e.g., `Create External Reference`, `Link Media Reference`, `Create External Standard`).
-- **Reference Data**: Attach valid values from a `ValidValueDefinition`/`ValidValueSet` to existing elements, and manage the type-system-level valid-metadata-value registry (e.g., `Link Element to Valid Values`, `Link Reference Value Assignment`, `Link Specification Property Assignment`, `Setup Valid Metadata Value`, `Set Consistent Metadata Values`). The `ValidValuesAssignment` relationship also has two contextual variants living in their natural families rather than here: `Link Question to Valid Values` (Glossary) and `Link Data Field to Valid Values` (Data Designer) — all three share one dispatcher-level processor (`ReferenceDataLinkProcessor` in `md_processing/v2/reference_data.py`).
+- **Reference Data**: Author business value lists and attach them to elements. `Create Reference Data Set` / `Create Reference Data Value` create `ReferenceDataSet` / `ReferenceDataValue` elements (the shape Egeria's own content uses). A set's members can be linked (`Members`), created inline one per line (`Values`, where commas are part of the value), or created with their own properties from a markdown table (`Value Table`: Value, Display Name, Description, Usage, Data Type, Is Case Sensitive, Default, Ordinal). Inline values are named `<set qualified name>::<value>`, so re-running a document updates them in place; members no longer listed are unlinked, never deleted. Relationships between values: `Link/Detach Valid Value Member`, `Consistent Valid Values`, `Associated Valid Values`, `Mapped Valid Values`, `Valid Value Implementation`. Assigning a set to an element: `Link Element to Valid Values` (with `Strict Requirement`) and `Link Reference Value Assignment`; the contextual variants `Link Question to Valid Values` (Glossary) and `Link Data Field to Valid Values` (Data Designer) share `ReferenceDataLinkProcessor` (`md_processing/v2/reference_data.py`). Note: the Reference Data view's finds default to type `ReferenceDataValue`, so a plain `ValidValueDefinition` is invisible to them unless the type is passed.
+- **Valid Metadata**: Manage the allowed values of Egeria's own properties (the type-system-level registry Dr.Egeria itself validates "Valid Value" attributes against) — `Setup`/`Clear Valid Metadata Value`, `Map Name` and `Map Value`, `Set Consistent Metadata Values`, and `Link`/`Detach Specification Property Assignment`. `Setup Valid Metadata Value` accepts a `Metadata Value Table` (Preferred Value, Display Name, Description) to set up several values for one property in one command. Split out of Reference Data on 2026-10-13; command names are unchanged.
 - **Views & Reports** (formerly **Report**): Run and author report specs (`FormatSet`s), and compose them — plus real Egeria `Report` assets and literal markdown text — into user-authored Dashboard Sheets:
   - `View Report`: Run a report spec ad hoc, supplying execution parameters (search string, output format, `Report Parameters` for a find-method spec's non-standard parameter, `Analytic Parameters` for an analytic-function spec's parameters, ...) at run time — no persistent element created.
   - `Create Report`: Persist a real Egeria `Report` asset that names a report spec and pins its own default execution parameters (including, for an analytic-function-backed spec, `Analytic Parameters`; or, for a report spec's action needing a parameter outside the standard find/search set — e.g. `collection_guid` for the `Collection Members` report — `Report Parameters` — see [`output-formats-and-report-specs.md`](output-formats-and-report-specs.md) for the find-method vs. analytic-function distinction), so it can be referenced by name and placed on a dashboard.