Why they exist

Every mutation of an order’s delivery state — advancing the transport ladder, assigning/reassigning a driver, dispatching to an external service, viewing customer PII on the available-orders board — is gated by these two checks. The defaults cover the standard driver/vendor/manager model; the filters are the escape hatches for custom role schemes (e.g. a dispatcher role) without forking the plugin.

The acting user is always resolved from the app token (mam_user_id()) or the WordPress session — never from request parameters.

mam_wc_delivery_user_can_manage_transport

Signature

apply_filters( 'mam_wc_delivery_user_can_manage_transport', bool $allowed, int $user_id, int $order_id );

Default rules — $allowed is true when the user is any of:

1. A store manager (manage_woocommerce capability), or
2. The order’s assigned driver (assigned_to_driver order meta equals the user) — except for assignment/reassignment and external-dispatch decisions, where the assigned driver is deliberately excluded, or
3. Vendor staff of the order: the user belongs (per WC_Product_Vendors_Utils::get_all_vendor_data()) to the vendor of any line item on the order.

Where it gates

• Advancing the transport status (mam_check_in / mam_wc_pv_complete_order_check_in).
• Assigning or reassigning a driver other than yourself, and reassignment of an already-claimed order.
• Dispatching to a third-party driver service (DoorDash).
• Showing customer PII for unclaimed orders on the available-orders board.
• A fallback check inside mam_ride_share_driver_update when the current assignment isn’t the acting driver’s.

mam_wc_delivery_user_can_claim_order

Signature

apply_filters( 'mam_wc_delivery_user_can_claim_order', bool $allowed, int $user_id, int $order_id );

Default rules — $allowed is true only when all hold:

1. The user has the driver role.
2. The order has no assigned_to_driver yet.
3. The order is awaiting a driver — pending_driver_assigment meta exists or transport_status is driver_assigned.
4. Any selected driver in the request is the acting user themselves (drivers can only claim for themselves).

A passing claim still goes through the per-order atomic claim lock, so two simultaneous claimers can both be “allowed” and exactly one will win the write.

Example — let a custom dispatcher role manage everything

add_filter( 'mam_wc_delivery_user_can_manage_transport', function ( $allowed, $user_id, $order_id ) {
    if ( ! $allowed && user_can( $user_id, 'my_dispatcher_cap' ) ) {
        $allowed = true;
    }
    return $allowed;
}, 10, 3 );

Example — restrict claiming to punched-in drivers

add_filter( 'mam_wc_delivery_user_can_claim_order', function ( $allowed, $user_id, $order_id ) {
    if ( $allowed && get_user_meta( $user_id, 'tsl_activity_user_is_punched_in', true ) != 1 ) {
        $allowed = false; // must be on duty to claim
    }
    return $allowed;
}, 10, 3 );

Notes

• Returning true from either filter bypasses real security checks — scope overrides narrowly.
• A check-in that fails both checks responds {"status":"failed","message":"Not authorized"}.

Related articles

• Hooks: mam_check_in and order advancement
• Recipe: Set up delivery drivers
• Plugin: mam-woocommerce-delivery

Metadata