AccessDecision
in package
The full outcome of an access check, including the CONTRACT.md §11 rule 9 `reason_code`.
AuthzRestClient::checkAccess() and AuthzRestClient::batchCheck() return
bare bools that predate this field and cannot carry it; use
AuthzRestClient::checkAccessDecision() /
AuthzRestClient::batchCheckDecisions() when the distinction matters.
Table of Contents
Properties
- $allowed : bool
- $reason : string|null
- $reasonCode : string|null
Methods
- __construct() : mixed
Properties
$allowed read-only
public
bool
$allowed
$reason read-only
public
string|null
$reason
$reasonCode read-only
public
string|null
$reasonCode
Methods
__construct()
public
__construct(bool $allowed, string|null $reason, string|null $reasonCode) : mixed
Parameters
- $allowed : bool
-
Whether the checked action is permitted. This property alone carries the outcome —
$reasonCodeexplains it and never contradicts it. - $reason : string|null
-
The server's human-readable explanation, when it sent one.
- $reasonCode : string|null
-
ReasonCode::ALLOWED, ReasonCode::NO_GRANT or ReasonCode::DENIED_BY_RULE.
The two refusals mean opposite things to the person on the other end.*
no_grantsays ask an admin for access;denied_by_rulesays an admin has already decided. An application that cannot tell them apart sends users to raise tickets that will be refused — which is why the contract forbids collapsing them into a barefalse.nullwhen the server omits the field, so a newer SDK against an older server degrades rather than failing. An unrecognised value is surfaced verbatim and never changes$allowed— which is why this is astringrather than an enum.