Repository navigation
Submission Moderation
When a submission is found to be cheating, a user with the Invalidate cheating submissions (Fake) permission for it can mark it Fake: click the submission's status at the top of its page, choose Fake (disqualify) and confirm. Its status becomes Fake and its score counts as 0. This works for ordinary and contest submissions. An explicit allow or deny of FakeSubmission decides who may do it; without one, whoever may delete the submission may also mark it Fake.
The submission's ID, code, answer file and original judging results are kept as evidence, and its page shows them separately from the zero score. Marking a submission Fake twice, or by two people at once, changes the statistics only once.
Marking a submission Fake cancels any judging still in progress and ignores results that arrive later. The accepted counts of the submitter and the problem, and cached score statistics, are updated; contests and assignments count the submission as 0. The submission itself stays in the submission history.
Rejudging a Fake submission clears the Fake mark and judges it again. This needs both the rejudge permission and the Fake permission for that submission (an explicit Fake denial also blocks it), so the rejudge permission alone can't undo moderation, and rejudging many submissions at once doesn't clear Fake marks. The rejudge keeps the Fake result among the submission's earlier results (the five most recent); export the evidence first if you need it for longer.
In contests:
- NOI / OI: if the last submission is Fake, the problem scores 0.
- IOI: the best other valid submission to the problem counts instead.
- Strict IOI: each subtask's best result comes from valid submissions only, never from Fake or Hacked ones.
- ICPC: a Fake submission counts as a wrong attempt.
A Fake submission never counts as accepted, and score histograms leave it out.
A successful Hack similarly marks its target Hacked with a score of 0 and keeps the evidence. Restoring a hacked submission needs the rejudge permission and the permission to manage Hacks (problem and contest managers have it unless explicitly denied); it judges the submission again rather than restoring its old result. The successful hack stays on record and can't void the restored submission a second time.
Marking and restoring are recorded in the audit log. Submissions in private teams still need team access, and being able to see a scoreboard doesn't let anyone see other users' code.
Installations upgrading from before this feature add Fake and then Hacked to the end of the submission.status values, keeping the existing values in order (a version that already has Fake is accepted too). The upgrader checks this; see Feature upgrades.
简体中文
- LLMOJ Wiki
- AI 环境与固定限制
- AI
- 后端配置
- 功能升级与数据库修改
- 配置总览
- 比赛赛制
- 分布式评测
- Docker 源
- 环境变量与维护脚本
- 前端配置
- HTTPS 与反向代理
- Hack
- 安装与端口配置
- 评测配置与扩缩容
- 安装后运维
- 发布源码与 Wiki
- 新用户注册审核
- 远程评测机
- NOI / OI 比赛自测(Self Eval)
- 题解
- Fake 处罚
- 提交记录
- 团队
- 两步验证
- 升级
English
- LLMOJ Wiki
- AI
- AI environment and fixed limits
- Backend configuration
- Feature upgrades and database changes
- Configuration overview
- Contest rules
- Distributed judging
- Docker sources
- Environment variables and maintenance scripts
- Frontend configuration
- HTTPS and reverse proxies
- Hacks
- Installation and ports
- Judge configuration and resizing
- Operations
- Publishing source and the wiki
- Registration approval
- Remote judges
- Self Eval in NOI / OI contests
- Solutions
- Fake moderation
- Submissions
- Teams
- Two-factor sign-in
- Upgrading