Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Apeuriox/lazybot-renewal/llms.txt

Use this file to discover all available pages before exploring further.

Lazybot ships with a lightweight permission system that allows commands to be disabled at different granularities without redeploying the bot. The PermissionChainHandler (the first link in the command chain, running at @Order(0)) queries PermissionService for each incoming command and halts execution with a user-friendly error message if a restriction is in effect. Administrators can bypass these checks entirely by being present in the hardcoded bypass list.

​
Permission Scopes

ScopeKeyTarget IDEffect when disabled
CHANNEL"CHANNEL"QQ group IDCommand is refused in the specific group channel with the message “此指令已在本群禁用”
GLOBAL"GLOBAL"0 (fixed)Command is refused everywhere with the message “此指令已被开发者禁用”
USER"USER"Sender’s user IDPer-user restriction (present in the source but currently commented out — not enforced)
Scopes are checked in a fixed order on every QQ command invocation:
  1. CHANNEL check first — a per-group disable stops execution before the global check is even reached.
  2. GLOBAL check second — a developer-level disable applies bot-wide.
  3. USER check — the code is present as commented-out lines in PermissionChainHandler and is not active in the current build.
PermissionService.checkPermission(type, id, command, version) returns true if the command is permitted and false if it is disabled. An unexpected exception from the permission service itself is also treated as a hard stop — the chain is halted with the message “权限检查失败，已跳过执行” to prevent accidental permission bypass due to database errors.
The administrator bypass in PermissionChainHandler is a hardcoded list of QQ user IDs:
private final List<Long> adminBypass = List.of(1524185356L);
If you are self-hosting Lazybot, you must update this list in the source before building and deploying, replacing the default IDs with your own. A user with one of these IDs has unconditional access to every command regardless of any channel or global disable rules.There is also a separate AuthorityVerifier.adminMap used by other admin utilities (such as permission-management commands). The map in the current source is:
// "Long ass numbers are discord ids" (source comment)
adminMap = Map.of(
    1524185356L,        true,   // QQ ID
    412246007024451585L,true,   // Discord ID
    1204694006L,        true    // QQ ID
);
This map mixes QQ user IDs and a Discord user ID. Update all three entries (and adminBypass) before deploying.

​
The /verify Command

The /verify command (VerifyCommand, mapped to "verify") is an admin-facing tool for verifying user identity records. It is implemented in command/manage/VerifyCommand.java and delegates to ManageService.verify(VerifyParameter). 
/verify <parameters>
The caller’s QQ ID is automatically set from the event sender. The command validates the supplied parameters and returns a status string.
Because VerifyCommand does not carry a @LazybotRateLimit annotation, it is not rate-limited by RateLimitHandler. However, any permission rules configured for the "verify" command via PermissionService still apply unless the caller is in the adminBypass list.

Build docs developers (and LLMs) love

Get started for freeTalk to us