dohertj2/3yearplan
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Mark corrections-doc B1 (data-path ACLs) and C5 (consumer cutover scope) as RESOLVED. B1: OtOpcUa team has designed and committed the OPC UA client data-path authorization model in lmxopcua/docs/v2/acl-design.md (decisions #129–132) covering NodePermissions bitmask flags for Browse/Read/Subscribe/HistoryRead/WriteOperate/WriteTune/WriteConfigure/AlarmRead/AlarmAck/AlarmConfirm/AlarmShelve/MethodCall plus common bundles, 6-level scope hierarchy with default-deny + additive grants, NodeAcl table generation-versioned alongside the rest of the content, cluster-create workflow seeding the v1 LDAP-role-to-permission map for v1 → v2 consumer migration parity, Admin UI ACL tab with bulk grant + permission simulator, denied-only audit logging; the "must work from day one of Tier 1 cutover" timing constraint is satisfied because Phase 1 (Configuration + Admin scaffold) completes before any driver phase. C5: consumer cutover (ScadaBridge / Ignition / System Platform IO) is OUT of v2 scope per lmxopcua decision #136 — OtOpcUa team's scope ends at Phase 5 (all drivers built, all stability protections in place, full Admin UI shipped including ACL editor); cutover sequencing per site, validation methodology, rollback procedures, and Aveva-pattern validation for tier 3 are deliverables of a separate integration / operations team that has yet to be named. Plan should explicitly assign ownership of the cutover plan to that team and link to their forthcoming doc.

Browse Source 
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Joseph Doherty
2026-04-17 11:58:54 -04:00
parent bed8c8e12b
commit dee56a6846
1 changed files with 15 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
handoffs/otopcua-corrections-2026-04-17.md
View File

@@ -71,6 +71,17 @@ The v1 LmxOpcUa LDAP layer (`Security.md`) maps LDAP groups to OPC UA permission
This is a substantial missing surface area in both the handoff and the v2 design. Suggest the plan add this as an explicit Year 1 deliverable alongside driver work, since Tier 1 (ScadaBridge) cutover will need authorization enforcement working from day one to satisfy "access control / authorization chokepoint" responsibility.
**Resolution** (lmxopcua decisions #129–132, 2026-04-17): the OtOpcUa team has designed and committed the data-path ACL model in `lmxopcua/docs/v2/acl-design.md`. Highlights:
- `NodePermissions` bitmask enum covering Browse / Read / Subscribe / HistoryRead / WriteOperate / WriteTune / WriteConfigure / AlarmRead / AlarmAcknowledge / AlarmConfirm / AlarmShelve / MethodCall, plus common bundles (`ReadOnly` / `Operator` / `Engineer` / `Admin`)
- 6-level scope hierarchy (Cluster / Namespace / UnsArea / UnsLine / Equipment / Tag) with default-deny + additive grants and Browse-implication on ancestors
- `NodeAcl` table is generation-versioned (decision #130) — ACL changes go through draft → diff → publish → rollback like every other content table
- Cluster-create workflow seeds default ACL set matching the v1 LmxOpcUa LDAP-role-to-permission map (decision #131), preserving behavioral parity for v1 → v2 consumer migration
- Per-session permission-trie evaluator with O(depth × group-count) cost; cache invalidated on generation-apply or LDAP group cache expiry
- Admin UI ACL tab + bulk grant + permission simulator
- Phase 1 ships the schema + Admin UI + evaluator unit tests; per-driver enforcement lands in each driver's phase (Phase 2+) per `acl-design.md` §"Implementation Plan"
The "must be working from day one of Tier 1 cutover" timing constraint is satisfied — Phase 1 (Configuration + Admin scaffold) is completed before any driver phase, so the ACL model exists in the central config DB before any driver consumes it.
---
### B2. Equipment-class templates dependency on the not-yet-created `schemas` repo blocks more than canonical-model integration
@@ -209,6 +220,10 @@ Or alternatively, the cutover plan lives outside the OtOpcUa v2 design and is ow
**Recommendation:** the cutover plan needs an owner and a doc. Either OtOpcUa team owns it (add Phases 6–8 to v2 plan) or another team owns it (handoff should name them and link the doc).
**Resolution** (lmxopcua decision #136, 2026-04-17): consumer cutover is **OUT of v2 scope** for the OtOpcUa team. The OtOpcUa team's responsibility ends at Phase 5 — all drivers built, all stability protections in place, full Admin UI shipped including the data-path ACL editor (per the §B1 resolution). Cutover sequencing per site, validation methodology, rollback procedures, and Aveva-pattern validation for tier 3 (System Platform IO) are deliverables of a separate **integration / operations team** that has yet to be named.
The plan should explicitly assign ownership of the cutover plan to that team and link to their (forthcoming) doc, replacing any wording that implies the OtOpcUa team owns end-to-end through tier 3. The handoff §"Rollout Posture" tier 1/2/3 sequencing remains the authoritative high-level roadmap; the implementation-level plan for it lives outside OtOpcUa's docs.
---
### C6. Per-building cluster pattern (Warsaw) — UNS path interaction needs clarification