Approvals

cohostly approvals is one inbox for every request that waits on a person. Think of the "in tray" on a manager's desk. Some papers are for you to sign, some are yours waiting on someone else, and some are already filed.

Deploy requests held by a ship policy also show up here. For how an app raises its own requests, see the approvals binding.

Usage

cohostly approvals [needs-me | waiting | history] [--project <name>] [--json]
cohostly approvals show <id>
cohostly approvals approve <id> [--note <text>]
cohostly approvals deny <id> [--note <text>]
cohostly approvals bulk <id> <id> ... [--deny] [--note <text>]
cohostly approvals rules <project>
cohostly approvals allow <project> <action> --per-request <N> --per-day <N> [--days <N>] [--unit <word>]
cohostly approvals revoke-rule <project> <rule>
cohostly approvals away [<email> [--days <N>]]
cohostly approvals end <delegation>

The three tab commands take --project as a filter. rules, allow and revoke-rule take the project as a plain word.

The tabs

show

cohostly approvals show <id>

Prints one request in the platform's own words:

<id>  [<risk>]  <headline>
  The app wrote: <the app's own sentence>
  Why: ...
  Now: ...
  If approved: ...
    - <change>
  <status>[, open until YYYY-MM-DD][, decided by X for Y (channel)]
  Can decide: A, B

The headline is written by the platform. What an app wrote is shown apart, after The app wrote:, so an app cannot dress its own words up as the platform's.

approve and deny

cohostly approvals approve <id> --note "checked the diff"
cohostly approvals deny <id> --note "not this week"

The CLI fetches the request and prints it, then sends your decision with the request's fingerprint (a short hash of its details). If the request changed after you read it, the platform refuses: This approval changed since you opened it, so your answer was not recorded. Open it again and check what it says now. Nothing asks you to confirm.

The answer is the platform's note, for example Your answer is recorded. 1 of 2 approvers have approved. or This approval is now approved.

Careful A request carries a fingerprint so a decision cannot be applied to something that changed. Always read show first.

bulk

cohostly approvals bulk <id> <id> <id> [--deny] [--note <text>]

Decides several requests in one go. Up to 25, all low-risk app actions, all of the same kind. Otherwise: Only low-risk app actions can be decided together. Decide these one at a time: <ids>. It prints one line per id: <id> <status> or <id> not decided: <error>.

rules, allow and revoke-rule

An always-allow rule lets a narrow kind of app action pass without asking you each time.

cohostly approvals allow shop send_email --per-request 5 --per-day 20 --days 30 --unit emails
cohostly approvals rules shop
cohostly approvals revoke-rule shop <rule>

• The action key is lower-case letters, digits and . _ : -.
• Making or revoking a rule needs a project admin. An assistant cannot make one.
• A rule never covers a high-risk request.
• allow prints the rule as a sentence, for example tool may send email up to 20 emails a day.
• rules lists <id> active|ended <sentence> (N used today).

away and end

cohostly approvals away alex@example.com --days 14
cohostly approvals away
cohostly approvals end <delegation>

away <email> hands your decisions to someone for a while. The default is 7 days and the most is 30. The person must already have an account and share one of your accounts, and cannot be you. It ends by itself. away with no email lists those you gave and those you received (<id> you -> <to>, until <date>). end <id> prints Your decisions are yours again. An assistant cannot start a handover.

What kinds of request exist

access_request exists as a name but nothing can create one yet.

Rules the platform enforces

• A request is refused if you are not eligible, it was already decided, or its details changed since you read it.
• No self-approval applies to deploy, make_public and spend_raise: the person who asked cannot decide it while another eligible person exists. It does not apply to an app's own request, where the person whose click triggered the app can approve it.
• A request made by an assistant or a service key cannot be decided by an assistant or a service key.
• High-risk requests (make_public, spend_raise) cannot be in a bulk decision or an always-allow rule. Only decisions from email and Telegram links are refused for them. The CLI and the dashboard can decide them.

Careful Deploy requests have a separate quirk. A deploy made from the CLI is made by a key, and a key cannot approve a deploy request another key made. Approve those in the dashboard. See ship.

Files read and written

None. Uses the saved key (or PLATFORM_API_KEY) and API_URL. Decisions are recorded with the channel cli. A network failure prints Fatal: TypeError: fetch failed.

Exit codes

0 on success, 1 on any failure, including a refused decision.

Examples

See what needs you, then read and approve one:

cohostly approvals
cohostly approvals show <id>
cohostly approvals approve <id> --note "looks right"

Clear three routine requests together:

cohostly approvals bulk <id1> <id2> <id3>

Cover for a week of leave:

cohostly approvals away alex@example.com --days 7

Related pages