Reports and tickets

The reports module lets players report a player or an issue, and lets staff handle these reports from menus. It also handles tickets, help requests sent to the staff. Options: config/reports.yml.

Player side

/reportplayer <player> [reason]    report a player        (alias /signaler)
/report [reason]                   report an issue        (alias /signalement)
/ticket <message>                  ask for help           (alias /aidestaff)
/mesreports                        follow your reports    (alias /myreports)

Players are told when their reports change status (taken, resolved, rejected) and, on login, get a reminder of their active reports and of the changes they missed.

Safeguards

Option	Default	Effect
require-reason	true	Reason required when no predefined reason exists (asked in chat otherwise)
reason-max-length	120	Maximum reason length
max-open-per-player	3	Maximum active reports per player (0 = unlimited)
deny-duplicates	true	Refuses a 2nd active report from the same player on the same target
tickets.max-open-per-player	2	Maximum open tickets per player

A delay between two reports is given by permission: cobaltstaff.report.cooldown.<duration> (e.g. cobaltstaff.report.cooldown.30s), and cobaltstaff.ticket.cooldown.<duration> for tickets. A player with cobaltstaff.reports.bypass cannot be reported (checked offline through LuckPerms).

Types and reasons

Four setups are possible:

No types or reasons

Free-text reason, typed in the command or asked in chat.

Types only

The player picks a type in a menu.

Reasons only

A reasons section at the root: the command’s reason is used, otherwise a menu opens. fixed-reason: true always forces the menu.

Types and reasons

Type menu, then the reasons of the chosen type (bundled setup).

The bundled types and reasons are written in French in config/reports.yml; translate them freely. Bundled types: Cheating (combat, fly/speed, X-ray, macro, other), Behaviour / chat (insults, spam, advertising, threats, other), Grief / theft, Scam and Bug (duplication, exploit, game issue).

types:
  triche:
    name: "<gradient:#FF5A5A:#C81E1E><b>ᴛʀɪᴄʜᴇ</b></gradient>"
    description:
      - "<gray>Cheat, client modifié, X-ray,"
      - "<gray>macro ou autoclick."
    item: iron_sword
    culprit: true          # only for a report on a player
    reasons:
      xray: {name: "<white>X-ray", description: ["<gray>Trouve les minerais trop facilement."], item: diamond_ore}
      autre: {name: "<white>Autre triche", item: paper, custom: true}   # asks the player for text

• culprit: true: only for a player report; false: only without a player; absent: both.
• custom: true: the reason asks the player for free text.
• item: a Minecraft material or a Nexo item id.

Attached evidence

• Chat messages: the reported player’s last messages (10 by default, less than 15 minutes old) are attached to the report.
• Position: the reported player’s position is saved if they are online, in addition to the reporter’s.

Lifecycle

1. OPEN — The report is created. Staff with cobaltstaff.reports.manage.view is notified, with clickable buttons (view, take, teleport).

2. IN_PROGRESS — A staff member takes it (reports.manage.accept). With claim-requires-staff-mode: true, staff mode is required. They can also step back from it.

3. RESOLVED or REJECTED — The assigned staff resolves it (reports.manage.resolve) or rejects it (reports.manage.reject), with a closing reason if closing-reason-enabled is on.

4. OPEN again — A report can be reopened, or taken away from its assignee (reports.manage.reopen-other).

5. DELETED — Deletion (reports.manage.delete): the report is hidden everywhere but kept in the history, or erased from the database with purge-deleted: true.

Each step is saved in the report’s history. Staff cannot handle a report that concerns themselves.

Staff management

/reports gerer [id] | accept <id>      management hub
/reports chercher id= reporter= assignee= status= culprit= type= kind=
/reports <player> [clear]              a player’s reports (list or clear)
/reports tp <id> [player]              to the report location, or to the reported player

The hub gives access to pending, in-progress and closed reports, your own reports, search and tickets. Lists can be filtered by status and type and sorted by date or by number of reports.

A report’s screen shows the reporter, target (online or not, frozen or not), reason, evidence, history, and buttons to the other modules: spectate, examine, freeze, record, notes, investigation and sanction. These buttons run configurable commands (actions) and are hidden if the command does not exist.

Staff notifications

Option	Effect
staff-notifications.permission	Permission to receive new reports
staff-notifications.update-permission	Permission for status changes
staff-notifications.sound	Notification sound
staff-notifications.on-join	Reminder on login if reports are still pending
staff-notifications.action-bar	Periodic action bar reminder for staff in staff mode

Note

With notifications.staff-mode-only: true (in config.yml, on by default), notifications are only received in staff mode.

Tickets

/ticket <message> creates a help request (200 characters max by default). Tickets show up in the hub, in a separate section, and are handled with cobaltstaff.tickets.manage.

Discussion channels

Each report can have a discussion channel between the reporter and the staff (disabled by default: channels.enabled).

/rc <id> <message>          talk in the channel
/canal rejoindre <id>       join the channel (staff)
/canal quitter <id>         leave the channel
/canal fermer <id>          close the channel (staff)

The channel opens automatically at the statuses listed in open-on (IN_PROGRESS by default) and closes at those in close-on (RESOLVED, REJECTED, DELETED).

Hooks

Commands can be run at each step: create-commands, accept-commands, reopen-commands, resolve-commands, reject-commands, delete-commands. Available variables: %id%, %type%, %reason%, %reporter%, %culprit%, %assigned%, %issuer%, %status%, %kind%, %hasculprit%. Format: see Hooks.