ores.inbox.approval_kind

Unique kind code, prefixed by the component that owns the kind.

Examples: 'iam.role_grant'.

Human-readable name for the kind.

std::string(faker::word::noun()) + " Request"

What the kind is for.

std::string(faker::lorem::sentence())

The permission a person needs to decide a request of this kind.

Examples: 'iam::roles:assign'.

std::string("iam::roles:assign")

The permission a person needs to raise a request of this kind, which is the maker's half of the maker and checker pair. It sits on the kind and never on a request: a maker who could name a weaker checker would choose their own control.

Examples: 'marketdata::curve_bootstrap:publish'.

Null when the kind names none, and then the raise is the component's own to gate, which is how every kind seeded before this column behaves. The permission is held by an account in the tenant and never by a party.

std::nullopt

Whether held is a state this kind uses.

Whether an approval needs a comment. A refusal always needs one.

The number of days after which an unanswered request closes as expired, or null when a request of this kind does not expire.

The type of the workflow that applies a request of this kind once every part has approved it, or null when the owning component applies the request itself.

The workflow is started with the request's id as its request, which is {"request_id": "<id>"}. Each definition reads that shape, so the inbox starts any kind's workflow without knowing what the kind changes.

The number of hours after approval during which a stopped apply is retried, or null when the kind names no apply workflow. When the window ends, the request moves to apply_failed with the reason "could not apply" and the person who asked is told, so a request never retries forever.

How many approvals, each by a different person, close a request as approved. It is the count of people, and never a way to say that nobody decides: a kind that needs nobody says so through auto_approval_code.

faker::number::integer(1, 2)

Which raises of this kind close without a person, and so which acts the installation does on its own behalf.

A maker and checker pair exists to put a second person in front of a consequential act a person proposed. Where no person is the maker, there is no judgement to check, and the request closes approved in the same act, with the system as its decider and a decision that says a policy closed it.

The values, and what each covers:

• none – a person decides, as the kind's count says. The default.
• system_tenant – a raise in the system tenant closes at once. The system tenant is the installation, so its own curves and datasets are the installation's own acts, done before any person would be on shift. A raise in any other tenant is somebody's book and waits.
• every_request – every raise of this kind closes at once, whatever the tenant. For kinds that record rather than control, and for a demonstration that must not wait on a click.

A raise that names parts is decided by its parts however this column reads: the parts are people answering, and a policy that skipped them would leave the parts open forever.

The policy is the kind's, so it is a versioned data change with who turned it on and why beside it, and the request and its decision state it in words. A deployment states whether it enforces approvals at all through system.approvals.mode, which closes every kind's requests at once when it is auto_approved.

Order for UI display purposes.

faker::number::integer(1, 100)

The permission a decider needs. Permissions are held by the system tenant, so the check reads it.

The permission a maker needs. Null names none, so the kind's raise stays the owning component's to gate.

The kinds are the system tenant's rows, and a decider of any tenant reads the rule of the kind it answers: how many approvals it needs, the permission it takes to decide, whether it holds, and when it expires. The policy lets a reader see its own tenant's kinds beside the system tenant's, and a write stays the caller's own.

A tenant session reads its own kinds and the system tenant's, because the kind a request is of is the system's and its rule is what a decider reads.