Role Configuration Admin

PortalRoleAdmin is the administration page for portal roles: which roles the portal has, and which of them a newly registered user is given. It ships with the framework on both stacks, so a portal picks up improvements to it by updating its packages — the page you write is the role gate and the heading.

What's on the page

Two grids, each with New, Open and Delete. Every change is written as soon as you save or delete it — there is no page-level Save.

• Portal roles — a name and a description, edited in a side panel. What a role grants is not configured here: it is bound to the role's name in code at startup, so adding a role makes it assignable rather than powerful, and renaming one detaches it from what it grants.
• Role configurations — which role a newly registered user is given, and when — to nobody, to everybody, or to whoever matches a rule you write.

Rules that decide who qualifies

A rule is a FetchXML query over contact. When someone registers, the portal narrows the query to that contact and assigns the role if Dataverse returns them. Joins to related tables are honoured, and columns, sorts and top make no difference to the answer, so a query copied from a view works as it is.

In React the rule is written with the FetchXML query builder, pinned to Contact with aggregates switched off, on a page of its own so the builder has room. Run shows the contacts the rule matches today — the only way to find out whether it selects the people you meant.

In Blazor the same column is edited as FetchXML text; there is no Blazor query builder yet.

A broken rule fails quietly

A rule that is empty, is not valid FetchXML, is an aggregate query, or is rooted in a table other than Contact matches nobody. Nothing reports it as an error — the role is simply never assigned. The React editor warns about each of these above the builder while you write the rule.

Adding it to your portal

Both project templates already include this page at /RoleConfigurationAdmin, under the Admin menu. To add it yourself, gate a page with [AuthorizeSystemAdmin] and <SystemAdminView> — in React, useIsSystemAdmin() — and drop the component in:

The configuration page (React)

configurationUrl opens a configuration on its own page instead of in a side panel. Leave it off and the panel is used, which works but leaves the query builder little room. The page it points at supplies the record context and the Save button; the form itself is the framework’s PortalRoleConfigurationForm:

Web roles under enhanced authorization

On a portal running enhanced authorization, users are given Power Pages web roles rather than portal roles: Power Pages grants each user the Dataverse security role it pairs with each of their web roles, and what that role allows comes from the site's table permissions. WebRoleAdmin is the counterpart of PortalRoleAdmin for that model, with three grids: the site's web roles, their table permissions — which table, which rows, which operations, and which web roles each applies to — and the rules that hand web roles to new users, written exactly as above. The rules live in the Power Portals Pro Enhanced Authorization solution, which needs Power Pages installed in the environment.

Both project templates show whichever page applies: the Admin menu offers Web Roles when enhanced authorization is on and Role Configuration when it is off. Your own navigation can make the same choice with ISecurityModelInfo.IsEnhancedAuthorizationEnabledAsync() in Blazor or useAuthOptions() in React, both answered from GET /api/auth/options.

A table permission's table and relationships are chosen from the environment's metadata rather than typed, because a misspelled name is accepted and grants nothing. The relationship fields follow the access type: Contact and Account ask how a row reaches the user's contact or account, Parent asks for the parent permission and how a row reaches its table, and Custom asks for a FetchXML filter — written with the FetchXML query builder in React, and as text in Blazor. A permission's web roles are saved with it, a new permission's included; the grid edits one permission at a time for that reason.

Changes reach Dataverse through Power Pages

Web roles and table permissions are Power Pages' own records, so this page and the Power Pages Management app edit the same data, and only the site in SecurityOptions.DataverseSecurity.PowerPagesSiteId is shown or changed. Power Pages turns a web role's table permissions into the security role it pairs with the web role, on its own schedule: a new web role grants nothing until that pairing exists, and role and privilege changes can take a minute or two to reach a signed-in user. A rule naming a web role of a different site is skipped, and the portal logs it.

API reference

PortalRoleConfigurationForm

WebRoleAdmin

WebRoleConfigurationForm

WebRoleForm

TablePermissionForm