9cad9ed0fc
v2-ci / build (push) Failing after 41s
v2-ci / unit-tests (tests/Core/ZB.MOM.WW.OtOpcUa.Cluster.Tests) (push) Has been skipped
v2-ci / unit-tests (tests/Server/ZB.MOM.WW.OtOpcUa.ControlPlane.Tests) (push) Has been skipped
v2-ci / unit-tests (tests/Server/ZB.MOM.WW.OtOpcUa.OpcUaServer.Tests) (push) Has been skipped
v2-ci / unit-tests (tests/Server/ZB.MOM.WW.OtOpcUa.Runtime.Tests) (push) Has been skipped
v2-ci / unit-tests (tests/Server/ZB.MOM.WW.OtOpcUa.Security.Tests) (push) Has been skipped
v2-ci / integration (tests/Server/ZB.MOM.WW.OtOpcUa.Host.IntegrationTests) (push) Has been skipped
v2-ci / integration (tests/Server/ZB.MOM.WW.OtOpcUa.OpcUaServer.IntegrationTests) (push) Has been skipped
Adds <summary>/<param>/<returns>/<inheritdoc> where missing and removes project bookkeeping IDs (task/tracking refs) from shipped code comments, so the docs read cleanly and CommentChecker is quiet except for known false positives (PLC/protocol terms, event/IEqualityComparer inheritdoc). Doc/comment-only; no logic changed; solution builds clean.
38 lines
2.0 KiB
C#
38 lines
2.0 KiB
C#
namespace ZB.MOM.WW.OtOpcUa.Configuration.Enums;
|
|
|
|
/// <summary>
|
|
/// Admin UI roles per <c>admin-ui.md</c> §"Admin Roles" and Phase 6.2 Stream A.
|
|
/// These govern Admin UI capabilities (cluster CRUD, draft → publish, fleet-wide admin
|
|
/// actions) — they do NOT govern OPC UA data-path authorization, which reads
|
|
/// <see cref="Entities.NodeAcl"/> joined against LDAP group memberships directly.
|
|
/// </summary>
|
|
/// <remarks>
|
|
/// <para>
|
|
/// Per <c>docs/v2/plan.md</c> the two concerns share zero runtime code path:
|
|
/// the control plane (Admin UI) consumes <see cref="Entities.LdapGroupRoleMapping"/>; the
|
|
/// data plane consumes <see cref="Entities.NodeAcl"/> rows directly. Having them in one
|
|
/// table would collapse the distinction + let a user inherit tag permissions via their
|
|
/// admin-role claim path.
|
|
/// </para>
|
|
/// <para>
|
|
/// The member names were standardized on the canonical control-plane role vocabulary
|
|
/// (<c>ZB.MOM.WW.Auth</c> <c>CanonicalRole</c>): <c>ConfigViewer → Viewer</c>,
|
|
/// <c>ConfigEditor → Designer</c>, <c>FleetAdmin → Administrator</c>. The appsettings-only
|
|
/// <c>DriverOperator</c> string role likewise became <c>Operator</c>. These members persist
|
|
/// as their string names (EF <c>HasConversion<string></c>); the rename is paired with
|
|
/// a data migration (<c>CanonicalizeAdminRoles</c>) that rewrites existing rows. This is a
|
|
/// rename, not a permission change — enforcement semantics are preserved.
|
|
/// </para>
|
|
/// </remarks>
|
|
public enum AdminRole
|
|
{
|
|
/// <summary>Read-only Admin UI access — can view cluster state, drafts, publish history. (Canonical: Viewer; was ConfigViewer.)</summary>
|
|
Viewer,
|
|
|
|
/// <summary>Can author drafts + submit for publish. (Canonical: Designer; was ConfigEditor.)</summary>
|
|
Designer,
|
|
|
|
/// <summary>Full Admin UI privileges including publish + fleet-admin actions. (Canonical: Administrator; was FleetAdmin.)</summary>
|
|
Administrator,
|
|
}
|