Background

App-user invites live in mam-main as the private app_user_invite CPT (parented to an app_user post), scoped to a main_post_id and carrying a sub_role (e.g. manager, staff, driver). Sibling plugins create and read invites through filters (mam_invite_app_user_to_post_id, mam_get_invites_for_post_id, mam_update_user_invitation_to_post_id, …) and never touch the CPT directly.

These actions fire whenever an invite’s status actually changes, so a plugin can react to acceptance/decline without polling.

Signatures

// Generic — fires on every status transition.
do_action( 'mam_app_user_invite_status_changed', int $invite_id, int $user_id, int $post_id, string $sub_role, string $status );

// Convenience — one per status. {status} ∈ accepted | declined | revoked | pending.
do_action( "mam_app_user_invite_{$status}", int $invite_id, int $user_id, int $post_id, string $sub_role );

Hooks fire only on an actual transition (new status ≠ previous), from inside update_user_invitation_to_post_id() — which is the path taken by the in-app Accept/Decline buttons (mam_checkin_accept / mam_checkin_decline) and by do_action('mam_update_user_invitation_to_post_id', …).

Typical use — provision a user on accept

add_action( 'mam_app_user_invite_accepted', function ( $invite_id, $user_id, $post_id, $sub_role ) {
    // Example: a use-case plugin turns an accepted invitee into a driver
    // attached to the hotel listing's Product Vendors account.
    $vendor_id = (int) get_post_meta( $post_id, 'par_vendor_id', true );
    if ( ! $vendor_id ) {
        return;
    }
    $user = new WP_User( $user_id );
    $user->set_role( $sub_role ?: 'wc_product_vendors_manager_vendor' );
    update_user_meta( $user_id, 'parent_pv_account_id', $vendor_id );
}, 10, 4 );

Notes

• The Accept/Decline UI is provided generically by mam-main (add_invite_buttons on mam_hss_stack_after_nav_header) for any pending invite on the logged-in user — consumers only create the invite and react to these actions.
• sub_role is stored verbatim (sanitized text); there is no fixed enum, so 'driver' or any custom role string is valid.
• The previous status is read before the write, so re-saving the same status is a no-op and won’t re-fire the hooks.

Related articles

• Hook: mam_invite_app_user_to_post_id
• Recipe: Manage staff and managers (mam-geodirectory)

Metadata