Purpose

This page collects the status vocabularies that are reused across more than one CRM operator surface, so that the same label is read consistently wherever it appears.

Each section lists the observed values, what each value means for an operator, and which module owns the status. Values are derived from module fields.yaml evidence and the surface docs that describe them. Where a value set is not fully enumerated in the repo, the section says so rather than implying a complete authoritative list.

Account Operational Status

Owner module: players.

This is the simple account on/off state, separate from KYC.

• Source on the list and overview surfaces is player.isActive.
• Rendered as a badge or as a read-only Active / Inactive summary, and is editable through an Is Active switch in the overview status section.

Value	Meaning
Active	The account is enabled for normal play and operator workflows.
Inactive	The account is disabled; it is not the same as a KYC or compliance state.

Practical rule: do not read account status as a verification or compliance state. It only answers whether the account is enabled.

KYC / Review Status

Owner module: players (KYC).

This is the verification bucket, surfaced as its own badge and as a list filter (kycStatus). The shortcut tabs on the player list set this same filter.

• Source is player.kycStatus / params.kycStatus.
• The list exposes shortcut tabs that set kycStatus to specific buckets.

Value	Meaning	Evidence
PENDING	Awaiting review. The Pending KYC tab sets kycStatus=PENDING.	Evidenced
APPROVED	Verification accepted. The Approved tab sets kycStatus=APPROVED.	Evidenced
REJECTED	Verification refused. The Rejected tab sets kycStatus=REJECTED.	Evidenced
REQUESTED	Verification requested but not yet pending/approved. Seen in the pending-withdrawal KYC buckets (Kyc Requested).	Evidenced via report buckets

Practical rule: KYC status is a verification bucket and is independent of the account active/inactive state. The pending-withdrawal report family slices the umbrella pending amount into Kyc Pending, Kyc Requested, and Kyc Approved subsets of these same buckets.

Issued-Bonus Status

Owner module: bonuses (issued bonuses, surfaced under players bonus relations).

Two related lifecycle vocabularies appear on issued-bonus rows.

Bonus Status is the high-level lifecycle state of an issued bonus.

• Source is usersBonuses issued-bonus data.
• Operator meaning per the field docs is the current lifecycle state, filtered by values such as active, cancelled, expired, or win.

Value	Meaning
active	The issued bonus is live in the player's bonus flow.
cancelled	The issued bonus was cancelled out of the lifecycle.
expired	The issued bonus lapsed without completion.
win	The issued bonus reached a winning/settled outcome.

The repo evidences these four values as filter examples; treat the set as the documented common values rather than a guaranteed exhaustive enum.

Wagering Status is a separate progress vocabulary on the same row. It tracks the state of the wagering requirement rather than the bonus lifecycle. The repo describes it as a progress state but does not enumerate a fixed value list, so treat its value set as illustrative rather than authoritative, and read it alongside Wager Left.

Transaction Status

Owner module: transactions.

Transaction rows carry a numeric backend status that the frontend maps to display labels. The filter and the loaded row use different representations.

• Source is transaction.status.
• Backend row status is numeric (0..3) and the FE maps it to display labels.
• The filter sends string values such as pending, completed, failed, and rollback, while loaded rows return numeric codes.

Display label	Meaning
Pending	The transaction is awaiting resolution.
Complete	The transaction settled successfully.
Failed	The transaction did not succeed.
Rollback	The transaction was reversed.

Practical rule: the dedicated detail route can show the raw numeric value (0/1/2/3) because it does not always remap to the humanized list labels. Reconcile filter strings and row labels within the same surface only.

Address Status (related, players-owned)

Owner module: players.

Address Status is included here because it is reused but is easy to confuse: it carries two different meanings on the same surface.

• The upper profile row shows the saved address-validity flag (source player.addressIsValid) as Valid or Invalid.
• The lower Address Data card shows which address source is in use: User address (validated), Dummy address in use, User address (unvalidated), or Address missing.

Practical rule: do not treat the upper valid/invalid flag and the lower source-selection summary as the same value set.

How to use this page

1. Read the status label in the context of its owner module first.
2. Use the table for that vocabulary to confirm the meaning of each value.
3. For value sets marked as not fully enumerated or illustrative, verify the exact surface before rewriting operator wording.