- Currently the logging isn't that great, it uses fmt.Printf("xxx\n") where a error is being logged with no prefix or any idea which function called it. - This PR adds a logging module that is able to log to multiple sources, will display the date + time + filename + caller/linenumber of the function that called the log.XXX(), this should make the log file on the server-side more fun to read and easier to understand why something has errored. - I did touch some other lines not related to logging to make it more idiomatic. Co-authored-by: Gusted <firstname.lastname@example.org> Reviewed-on: #7 Co-authored-by: Gusted <email@example.com> Co-committed-by: Gusted <firstname.lastname@example.org>
|1 month ago|
|.woodpecker||2 months ago|
|backend||1 month ago|
|docker||2 months ago|
|frontend||2 months ago|
|.gitignore||2 months ago|
|LICENSE||7 months ago|
|Makefile||1 month ago|
|README.md||2 months ago|
Codeberg Moderation tools
This is an attempt to write a frontend that makes moderating Codeberg or other Gitea instances easier. Some functionality here is probably duplicated to the native Gitea tooling, but we think it's worth it.
This is not going to improve the Gitea moderation tools (although necessary):
- focus on batch operations and might be overkill to small instances
- runs as independent service and does not bloat Gitea codebase
- includes some codeberg-specific stuff, like license reminders, some custom abuse messages etc
The idea is pretty simple: You put a list of content you want to process, e.g. a list of repos.
You have a handful actions you can take on this, e.g. expand to the forks, or reduce only to the users of them.
Each plugin produces an output list, or multiple, and you can
TAKE them back as your next input.
Finally, you can act on the list, e.g. remove or lock, or quarantine, or send them an email.
We now decided to handle much of this in the backend, this frontend then calls this backend, that in term calls the Gitea API.
We want to build the service with as less need for server-side configuration, especially security tokens, as possible. Everything should be handled via client-side API tokens (or OAuth). The configuration of access levels should be handled with a Gitea org and teams in there.
I consider some features with about this priority (please check issues for detailed planning):
|upstream||remove spam users including their repos and orgs (currently not possible with Gitea, and annoying)|
|WIP||allow to quarantine repos more easily (needs expand to forks feature, @ashimokawa is working on it)|
|✅ upstream + here||delete issues completely (added to the Gitea UI now)|
|WIP (users ✅)||search for (spam) users and repos to more easily process them|
|✅||write a backend that allows to send emails|
|add some more features, e.g. a "Keep or Sweep" mode to quickly filter for unwanted content|
|issue||maybe add OAuth so the login is easier|
|after OAuth: allow users to report spam to this system, if Gitea still doesn't have a way to report content|
|maybe allow to grant access to more moderators (they could propose changes that are stored in an internal database and confirmed by admins)|
The Codeberg team is very open to your contribution. Since we are working nicely in a team, and this is a young project in the bootstrapping phase, it might be hard at times to get started (still check out the issues, we always aim to have some things to get you started).
Running the project on a GNU/Linux machine with recent Go and make installed,
running is as easy as moving the sample ini file to the same name without
make run in the project root (or the go run command in the backend folder).
If you prefer development via docker, you can find an unofficial guide in the
If you have any questions, want to work on a feature or could imagine collaborating with us for some time, feel free to ping us in an issue or in a general Matrix chatgroup.
This project is maintained by:
The system consists of the backend that handles the API queries from the frontend and maps them to Gitea API queries. Most logic, especially if it requires larger data transfers between the backend and the Gitea API, should be done on the server. The user interface should be as lightweight as possible, so moderators can also do operations on mobile and don't need to carry a powreful machine with them.
WTF what have you done to this SPA?
If you think this project needs to be done more serious, I'll gladly hand over the maintenance or accept contributions that increase maintainablity or speed up development. But as long as I'm the only one working on it, I'll try to avoid the tooling that creates headache for me.
Thank you for understanding :-)