Moderator workflow

Select the correct server and check connectivity first. Sections depend on the game, staff permissions and project feature matrix. An action existing in source does not establish support in the selected adapter.

Players and history

Player cards combine profile, server state, sessions, names, IPs, team history and available actions. Data sources differ: Steam data applies to Steam identities; Minecraft uses its own UUID and persistent string ID. Missing Steam/VAC fields do not mean zero statistics.

Team history and playing together are observations, not proof of shared account ownership. Check timezone, event time and project/server scope when reviewing history.

Chat, reports and questions

• Chat: browsing, filtering, replies, global messages, deletion and mute actions within permissions.
• Report: a player's allegation; review context before punishment. A report is not an inspection result.
• Question: a separate player conversation, distinct from an inspection or appeal.
• Notifications: server events and alerts with read/state handling; a suspicious VPN/IP is a signal for review.

Methods belong to chat, report, question and alert; parameters and feature keys are listed in the event reference.

Player inspection

The regular workflow uses check.call/start, messages/contact, notes, cancellation and completion. History is separate from current online state. Finish active checks explicitly; background cleanup also handles stale entries.

For Minecraft, the panel uses checker.createSession, then requestScan, sendMessage, close/cancel. A code grants access to a specific session; the player selects the directory and consents. scan.request does not start local inspection automatically. A server-side moderator verdict chooses the outcome, not a suspicious filename. See Minecraft.

Bans, mutes and evidence

Specify the correct player, server, reason and expiry. Check whether a particular action expects a duration or absolute timestamp. 0 can mean a permanent punishment in an adapter; do not assume that meaning for every HTTP field.

A banlog write and execution by a game server are separate stages. An ACK timeout does not establish that no database write occurred. Before retrying, inspect history and current state: a repeated request may duplicate an action.

ban.uploadProofs accepts multipart files after validating the account, server access and ban/server association. Keep evidence within its permitted audience. Mutes, unmutes, ban annulment/unban and cleanup have separate handlers and permissions.

Appeals

A player submits an appeal through the public/account flow. Staff list, take, update and reply through the panel. Internal integration transport is not a public API.

Game and service sections

Traps, drawings and sleeping bags depend on game extension capabilities; a menu item does not establish Minecraft/DayZ support. Audit records staff actions; statistics and combat events require their feature keys. Separate log deletion rights from viewing rights.

Sources: .web/src/domains/ozprotect/pages/new/panel, Network socket/client, modules/Check.js, CheckerSession.js, Banlog.js, BanProof.js, Appeal.js.