Operation Buttons

An operation button runs an operation the server registered — a custom API, a custom action, one of Dataverse's own messages, or code of your own — and shows only to the users it is registered for. The button asks the server once which operations the signed-in user may run, and checks each record it would send against what the user may do to it, so it doesn't offer what the server would refuse. The server still judges every request when it is sent.

Registering an operation

Register an operation in the server's Program.cs: AddOperationAccess for a Dataverse operation, AddOperationHandler for your own code. Inside AddPortalRole, WithOperationAccess and WithOperationHandler grant one to the role's holders. A registration says who may run the operation, the parameters a request may carry, the records they must point to and the outputs that come back.

• ForEveryone(), ForSignedInUsers(), ForContactsMatching(fetchXml) and ForWebRoles(...) say who may run it; a role's registration is for the role's holders. Under Dataverse-native security, contacts hold web roles rather than portal roles, and a custom API is offered only to users whose security roles grant its execute privilege.
• A request for your own code is judged exactly as a Dataverse operation's is: the handler sees only requests that passed, with the parameters the server sets filled in, and the caller sees only the outputs the registration returns.
• Your own code can't share Dataverse's transaction, so a request for it is sent on its own: a batch that carries it with anything else is refused.
• Security describes everything a registration can say.

OperationButton

Put an OperationButton where the operation belongs, naming the operation and the parameter its record goes in.

• It is hidden from users who may not run the operation, and while the answer is on its way; set WhenNotAllowed (whenNotAllowed) to disable it instead. The answer is asked for once and kept while the app is open; a request the server refuses asks for it again.
• The record goes in RecordParameter: Record, any record by reference, or else the record of the RecordContext the button sits in, once it is saved. The user must be able to act on it as the registration requires: a form's record says what the user may do to it, and a record named by reference is read for it.
• On a form, a Dataverse operation on the form's record is sent in the form's own save, after its changes, so both are saved or neither, and the record is read back. Your own code runs after the form's changes are saved.
• Parameters are sent with every request, and GetParametersAsync (getParameters) gathers more when the button is clicked, from a dialog, say; returning nothing cancels the click. ConfirmationMessage asks before the operation runs, and OnCompleted hands back its outputs.
• Set its text with Label or its content, and its icon, tooltip and appearance as on any other button.

OperationGridButton

In a grid's toolbar, OperationGridButton runs the operation once for each selected row, sending the row in RecordParameter, and then refreshes the grid. It is enabled while every selected row is one the user may act on, which each row says itself. A Dataverse operation's requests are sent in one transaction, so they all run or none do; your own code runs on one row at a time and stops at the first that fails.

Asking what the user may run

The buttons ask GET /api/permissions/operations, which answers for the signed-in user alone: every operation they may run, or just the ones you name, with what a request for each may carry and the records it must point to. Your own UI can ask the same through IOperationAccessCache or IPowerPortalsProService.GetOperationAccessForCurrentUserAsync on Blazor, and useOperationAccess or ppp.retrieveOperationAccessAsync on React.