- .env.example: REDMINE_URL/API_KEY and GITEA_URL/USER/PASSWORD/TOKEN
placeholders so a fresh clone surfaces the optional tracker/mirror
hookups without exposing real credentials.
- docs/notes/2026-06-08-dds-qa-session.md: personal session reference
covering DDS role model, scenario walkthrough, group/DB Link/Data
Catalog patterns, and the mapping-table vs declarative-DDL decision.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Real run against ADB 23.26.2.2.0 surfaced two issues:
- END USERs can't be direct grantees of a regular ROLE (ORA-01917).
Connection privilege must flow through a DATA ROLE — added
connect_only_role for ddsuser_none so it can authenticate
without holding any data grant (mirrors VPDUSER_NONE UX).
- DDS Data Grants on top of the shared v_customers_* views silently
returned 0 rows because the VPD policy on those views evaluates
1=0 for sessions whose LOGON trigger didn't load the VPD context
(i.e. all ddsuser_*). Created dedicated DDS-only views
(v_dds_customers_pg / v_dds_customers_my) so DDS Data Grants are
the sole authority.
E2E matrix now passes (ddsuser_my MY=17, ddsuser_pg PG=12,
ddsuser_both 12/17, ddsuser_none ORA-00942 on both). Notably DDS
returns ORA-00942 where VPD returned 0 rows — stronger object
hiding.
Expanded docs/05-dds-variant.md with:
- §1.1 capability matrix (End User, Data Role, Data Grant, MAC,
ORA_END_USER_CONTEXT, OAuth2 federation, End User Context Object,
ORA_IS_COLUMN_AUTHORIZED, dictionary views)
- §1.2 VPD/RAS-vs-DDS comparison
- §1.3 best-fit scenarios (multi-tenant SaaS, agentic AI, HR/PHI,
federated identity, compliance)
- §1.4 limitations
- §5 operation-level grant example (manager-only UPDATE salary)
- §8 actual E2E results table
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
