Phase 3 PR 29 — Account/session page with roles + capabilities #28
Assignees
dohertj2 (dohertj2)
Clear assignees
dohertj2 (dohertj2)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: dohertj2/lmxopcua#28
Reference in New Issue
Block a user
Delete Branch "phase-3-pr29-account-page"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Expands the minimal sidebar role display into a dedicated
/accountroute.What's shown
ClaimTypes.NameIdentifier) + display name (fromClaimTypes.Name).ClaimTypes.Role, populated from LDAP group mapping at sign-in).ldap_groupclaim thatLogin.razoralready adds).Program.cs'sAddAuthorizationBuilderpolicies + each page's[Authorize]attribute so operators can self-service check access without trial-and-error navigation.Capabilities covered:
CanEdit)CanPublish)Sidebar change
The 'Signed in as' line in
MainLayout.razornow wraps the display name in a link to/account. Sign-out stays where it is for muscle memory.Design notes
[Authorize](any authenticated user) — the capability table deliberately works for every signed-in session so operators can see what they don't have access to. Helps them file the right ticket with their LDAP admin instead of getting blank Access Denied after navigating blindly.Program.cs+ each page's[Authorize], and pulling it behind a service would just be indirection. A comment on the list reminds future-me to extend it when a new policy or[Authorize]page lands.Tests
No new tests — the page is pure display over claims; its only logic (Any-overlap between session roles and required roles) is what
[Authorize(Roles=...)]does in-framework, and mirroring that in a unit test would test ASP.NET rather than our code. Admin.Tests Unit stays 23 pass / 0 fail. Admin build clean — 0 errors, 0 warnings.Closes
The third of the three Admin UI gap items the user selected to complete this round (Fleet dashboard = PR 27, Cert trust = PR 28, Account page = this one). Driver-specific admin pages remain deferred until driver options are finalized.
Sidebar's 'Signed in as' line now wraps the display name in a link to /account so the existing sidebar-compact view becomes the entry point for the fuller page — keeps the sign-out button where it was for muscle memory, just adds the detail page one click away. Page is gated with [Authorize] (any authenticated admin) rather than a specific role — the capability table deliberately works for every signed-in user so they can see what they DON'T have access to, which helps them file the right ticket with their LDAP admin instead of getting a plain Access Denied when navigating blindly. Capability → required-role table is defined as a private readonly record list in the page rather than pulled from a service because it's a UI-presentation concern, not runtime policy state — the runtime policy IS Program.cs's AddAuthorizationBuilder + each page's [Authorize] attribute, and this table just mirrors it for operator readability. Comment on the list reminds future-me to extend it when a new policy or [Authorize] page lands. No behavior change if roles are empty, but the page surfaces a hint ('Sign-in would have been blocked, so if you're seeing this, the session claim is likely stale') that nudges the operator toward signing out + back in. No new tests added — the page is pure display over claims; its only logic is the 'has-capability' Any-overlap check which is exactly what ASP.NET's [Authorize(Roles=...)] does in-framework, and duplicating that in a unit test would test the framework rather than our code. Admin.Tests Unit stays 23 pass / 0 fail. Admin build clean. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>