- Implementation of milestone 5. from **Task F. Moderation features: Reporting** (part of [amendment of the workplan](https://codeberg.org/forgejo/sustainability/src/branch/main/2022-12-01-nlnet/2025-02-07-extended-workplan.md#task-f-moderation-features-reporting) for NLnet 2022-12-035):
`5. Forgejo admins can see a list of reports`
There is a lot of room for improvements, but it was decided to start with a basic version so that feedback can be collected from real-life usages (based on which the UI might change a lot).
- Also covers milestone 2. from same **Task F. Moderation features: Reporting**:
`2. Reports from multiple users are combined in the database and don't create additional reports.`
But instead of combining the reports when stored, they are grouped when retrieved (it was concluded _that it might be preferable to take care of the deduplication while implementing the admin interface_; see https://codeberg.org/forgejo/forgejo/pulls/7939#issuecomment-4841754 for more details).
---
Follow-up of !6977
### See also:
- forgejo/design#30
---
This adds a new _Moderation reports_ section (/admin/moderation/reports) within the _Site administration_ page, where administrators can see an overview with the submitted abuse reports that are still open (not yet handled in any way). When multiple reports exist for the same content (submitted by distinct users) only the first one will be shown in the list and a counter can be seen on the right side (indicating the number of open reports for the same content type and ID). Clicking on the counter or the icon from the right side will open the details page where a list with all the reports (when multiple) linked to the reported content is available, as well as any shadow copy saved for the current report(s).
The new section is available only when moderation in enabled ([moderation] ENABLED config is set as true within app.ini).
Discussions regarding the UI/UX started with https://codeberg.org/forgejo/design/issues/30#issuecomment-2908849
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/7905
Reviewed-by: Otto <otto@codeberg.org>
Reviewed-by: jerger <jerger@noreply.codeberg.org>
Co-authored-by: floss4good <floss4good@disroot.org>
Co-committed-by: floss4good <floss4good@disroot.org>
testing-integration / test-unit (push) Waiting to run
testing-integration / test-sqlite (push) Waiting to run
testing / backend-checks (push) Waiting to run
testing / frontend-checks (push) Waiting to run
testing / test-unit (push) Blocked by required conditions
testing / test-e2e (push) Blocked by required conditions
testing / test-remote-cacher (redis) (push) Blocked by required conditions
testing / test-remote-cacher (valkey) (push) Blocked by required conditions
testing / test-remote-cacher (garnet) (push) Blocked by required conditions
testing / test-remote-cacher (redict) (push) Blocked by required conditions
testing / test-mysql (push) Blocked by required conditions
testing / test-pgsql (push) Blocked by required conditions
testing / test-sqlite (push) Blocked by required conditions
testing / security-check (push) Blocked by required conditions
Follow-up of !6977
I was fooled by the fact that for SQLite the columns corresponding to `string` fields were created as `TEXT`; but this is not the case for PostgreSQL and MariaDB/MySQL. According to XORM default mapping rules[^1] _String is corresponding to varchar(255)_.
Therefore `abuse_report`.`remarks` should be of type `VARCHAR(500)` and `abuse_report_shadow_copy`.`raw_value` of type `LONGTEXT`.
### Testing
I have dropped the affected columns (or the entire tables) and checked that for PostgreSQL and MariaDB they are created with the correct type and also manually tested the abusive content reporting functionality in order to make sure that no DB error will be returned if for 'Remarks' a text longer than 255 characters is submitted or when a (big) shadow copy is created.
[^1]: https://xorm.io/docs/chapter-02/4.columns/
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8267
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: floss4good <floss4good@disroot.org>
Co-committed-by: floss4good <floss4good@disroot.org>
