AccountedPro - Buttons and actions

Buttons appear in three places, and all three are built the same way.

Placement	Acts on	Built in
Header	The list as a whole	Buttons panel
Row	One record	A Button element in a column
Bulk	Everything ticked	Buttons panel, or a child table block

Button settings

Setting	Values
Label	Text on the button
Icon	Optional, before the label
Style	Primary, Outline, Subtle, Danger
Ask before running	A confirmation message; blank means no prompt
After it runs	Reload the list, or Do nothing
Roles	Who sees it
Show this only when…	A condition on the row

What a button can do

Action	Use it for
Run a Server Script	Anything the site should do on the server
Call a whitelisted method	An endpoint that already exists in any installed app
Set a value	Change one field without opening the record
Open a URL	A report, another list, an external system
Go to a route	Another page in the Desk
New document	Start a record, pre-filled

Run a Server Script

Name an API-type Server Script. The app checks it is API type and whitelisted before calling it, and passes the arguments you define below.

Call a whitelisted method

Name any whitelisted method — frappe.client.set_value, one of your own app's endpoints, anything the browser could already call. Whitelisting is re-checked when it runs, so a method that is not whitelisted is refused rather than attempted.

Set a value

Pick Field and Set to. The document is loaded, the reader's write permission on it is checked, and it is saved through the normal path — so validations, before_save hooks and everything else run exactly as they would on the form. It is not a silent database write.

Open a URL, with values from the row

/app/dispatch-order/new?sales_order={{ name }}&customer={{ customer }}

Anything inside {{ }} is taken from the row, so one button can open a filtered list, start a related document already filled in, or hand a reference to an external system.

Arguments

Under What to send, each argument has:

Field	Meaning
Argument name	What the script receives it as
Source	Where the value comes from
Value	Which field, which answer, or a literal

Source	Takes the value from
The row	A field on the record the button is on
A fixed value	A literal you type
An answer	Something the reader was asked for (below)
The current filters	What the list is filtered by right now
The current user	Who is pressing it

Asking the reader something first

Ask the user for… collects values before the action runs. Each has a Question (the label), Stored as (the name the action receives), and a Type — Data, Small Text, Select, Link, Date, Check, Number. Mark one required and the dialog will not submit without it.

A rejection button that must capture a reason is exactly this: one prompt field, reject_reason, required, passed as an argument.

Who can press it

Roles decides who sees the button. Show this only when… decides which rows show it.

Both are re-checked on the server when the button is pressed, against the freshly loaded document — not against what the browser claimed. A client that hides a button is a client that can be told not to hide it, so the check that matters happens where the reader cannot reach it.

What the app cannot vouch for is what a Server Script does once called. The builder says so rather than implying otherwise.

Bulk actions

A bulk action runs over every ticked record. The same action types are available and the same role and condition checks are applied to each record; anything that fails is reported rather than skipped silently.

Child rows inside an expanded row can be selectable too, with their own bulk buttons — for receiving specific lines off an order rather than the whole thing.

After it runs

Reload the list refetches the rows, so the row shows its new state and any tab counts and cards catch up. Do nothing is right for a button that opened something elsewhere.