How do I run the approval_operations commands from the shell?

Sends raise_approval_request_request and prints raise_approval_request_response, so the shape is the protocol's and the meaning is the service's. It reads kind_code, reason, part_codes, in that order. The caller must have established a session first.

The command is shaped like this:

approval_operations raise-approval <kind_code> <reason> <part_codes>

It is addressed at inbox.v1.ops.raise_approval.

approval_operations raise-approval __none__ __none__ __none__

Sends withdraw_approval_request_request and prints withdraw_approval_request_response, so the shape is the protocol's and the meaning is the service's. It reads request_id, comment, in that order. The caller must have established a session first.

The command is shaped like this:

approval_operations withdraw-approval <request_id> <comment> [--version <v>]

It is addressed at inbox.v1.ops.withdraw_approval.

approval_operations withdraw-approval __none__ __none__

Sends decide_approval_request_request and prints decide_approval_request_response, so the shape is the protocol's and the meaning is the service's. It reads request_id, decision_code, comment, part_code, in that order. The caller must have established a session first.

The command is shaped like this:

approval_operations decide-approval <request_id> <decision_code> <comment> <part_code> [--version <v>] [--hold_reason_code <v>]

It is addressed at inbox.v1.ops.decide_approval.

approval_operations decide-approval __none__ __none__ __none__ __none__

Sends list_approval_queue_request and prints list_approval_queue_response, so the shape is the protocol's and the meaning is the service's. The caller must have established a session first.

The command is shaped like this:

approval_operations list-approval-queue [--offset <v>] [--limit <v>]

It is addressed at inbox.v1.ops.list_approval_queue.

approval_operations list-approval-queue

Sends list_my_approval_requests_request and prints list_my_approval_requests_response, so the shape is the protocol's and the meaning is the service's. The caller must have established a session first.

The command is shaped like this:

approval_operations list-my-approval-requests [--offset <v>] [--limit <v>]

It is addressed at inbox.v1.ops.list_my_approval_requests.

approval_operations list-my-approval-requests

Sends get_approvals_mode_request and prints get_approvals_mode_response, so the shape is the protocol's and the meaning is the service's. The caller must have established a session first.

The command is shaped like this:

approval_operations get-approvals-mode

It is addressed at inbox.v1.ops.get_approvals_mode.

approval_operations get-approvals-mode

Sends set_approvals_mode_request and prints set_approvals_mode_response, so the shape is the protocol's and the meaning is the service's. It reads reason, in that order. The caller must have established a session first.

The command is shaped like this:

approval_operations set-approvals-mode <reason> [--auto_approved <v>]

It is addressed at inbox.v1.ops.set_approvals_mode.

approval_operations set-approvals-mode __none__

Sends get_approval_request and prints get_approval_response, so the shape is the protocol's and the meaning is the service's. It reads request_id, in that order. The caller must have established a session first.

The command is shaped like this:

approval_operations get-approval <request_id>

It is addressed at inbox.v1.ops.get_approval.

approval_operations get-approval __none__

Sends expire_overdue_approvals_request and prints expire_overdue_approvals_response, so the shape is the protocol's and the meaning is the service's. A caller runs it before it has a session, so the command presents no token and refuses none.

The command is shaped like this:

approval_operations expire-overdue-approvals

It is addressed at inbox.v1.ops.expire_overdue_approvals.

approval_operations expire-overdue-approvals

Sends remind_expiring_approvals_request and prints remind_expiring_approvals_response, so the shape is the protocol's and the meaning is the service's. A caller runs it before it has a session, so the command presents no token and refuses none.

The command is shaped like this:

approval_operations remind-expiring-approvals

It is addressed at inbox.v1.ops.remind_expiring_approvals.

approval_operations remind-expiring-approvals

Sends retry_stalled_applies_request and prints retry_stalled_applies_response, so the shape is the protocol's and the meaning is the service's. A caller runs it before it has a session, so the command presents no token and refuses none.

The command is shaped like this:

approval_operations retry-stalled-applies

It is addressed at inbox.v1.ops.retry_stalled_applies.

approval_operations retry-stalled-applies

Sends get_approval_history_request and prints get_approval_history_response, so the shape is the protocol's and the meaning is the service's. It reads request_id, in that order. The caller must have established a session first.

The command is shaped like this:

approval_operations get-approval-history <request_id>

It is addressed at inbox.v1.ops.get_approval_history.

approval_operations get-approval-history __none__

Sends get_approval_parts_request and prints get_approval_parts_response, so the shape is the protocol's and the meaning is the service's. It reads request_id, in that order. The caller must have established a session first.

The command is shaped like this:

approval_operations get-approval-parts <request_id>

It is addressed at inbox.v1.ops.get_approval_parts.

approval_operations get-approval-parts __none__