Custom table actions

Your own buttons on a table's rows: approve, send, recalculate — anything the standard create/edit/delete set does not cover.

Setting one up

On the table:

• Action controller — the class under PageBlocks\App\Http\Controllers that handles the actions;
• Actions — the list itself. Each entry needs a label and a method, and may name its own controller to override the table default.

The method receives the request. Selected rows arrive in ids as a comma-separated list, with id holding the first of them — enough for a per-row action.

namespace PageBlocks\App\Http\Controllers;

use Boshnik\PageBlocks\Http\Request;

class OrderActions extends BaseController
{
    public function approve(Request $request)
    {
        $ids = array_filter(explode(',', (string) $request->get('ids')));

        Order::whereIn('id', $ids)->update(['approved' => 1]);

        return response()->success('Approved: ' . count($ids));
    }
}

Only what the table lists can run

The request carries an index into the saved action list, not a method name. The component looks the entry up on the table, takes the controller and method from there, and checks both against [A-Za-z0-9_]+.

This is the security model, not a formality

A method name in the request would make every public method of every controller callable from the manager. Because the list is the source of truth, adding a method to the controller does not expose it — it has to be listed on the table first.

An entry with no label or no method is skipped rather than drawn as a broken button.

Quick filters share the controller

The same class can offer toolbar filters: give it a quickFilters() method and its result becomes buttons. See Filtering.

Both are optional and independent — a controller may implement either, both or neither.