Ryan LerchandMathieu Fenniak
027fd3658a
**AI Disclosure:** This work was produced with the assistance of an artificial intelligence tool
## feat: Add admin endpoints for individual user email management
Add GET and DELETE endpoints at `/admin/users/{username}/emails` to allow
administrators to list and delete individual email addresses for users.
These API endpoints provide programmatic access to functionality that is
currently only available through the web UI:
- http://forgejo.example/admin/emails (delete individual email addresses)
- http://forgejo.example/admin/users/1 (view individual user's emails)
The new endpoints follow existing admin API naming patterns such as
`/admin/users/{username}/keys`, `/admin/users/{username}/orgs`, and
`/admin/users/{username}/quota`, providing consistent resource management
under the `/admin/users/{username}` namespace.
This complements the existing `/admin/emails` endpoint which lists all emails
across all users, providing administrators with granular control over
individual user email management.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org).
### Tests
- I added test coverage for Go changes...
- [ ] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I added test coverage for JavaScript changes...
- [ ] in `web_src/js/*.test.js` if it can be unit tested.
- [ ] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)).
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [x] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9594
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Ryan Lerch <rlerch@redhat.com>
Co-committed-by: Ryan Lerch <rlerch@redhat.com>
Integration tests
Thank you for your effort to provide good software tests for Forgejo. Please also read the general testing instructions in the Forgejo contributor documentation.
This file is meant to provide specific information for the integration tests as well as some tips and tricks you should know.
Feel free to extend this file with more instructions if you feel like you have something to share!
How to run the tests?
Before running any tests, please ensure you perform a clean build:
make clean build
Integration tests can be run with make commands for the appropriate backends, namely:
make test-sqlite
make test-pgsql
make test-mysql
Run tests via local forgejo runner
If you have a forgejo runner, you can use it to run the test jobs:
Run all jobs
forgejo-runner exec -W .forgejo/workflows/testing.yml --event=pull_request
Warning: This file defines many jobs, so it will be resource-intensive and therefore not recommended.
Run single job
forgejo-runner exec -W .forgejo/workflows/testing.yml --event=pull_request -j <job_name>
You can list all job names via:
forgejo-runner exec -W .forgejo/workflows/testing.yml --event=pull_request -l
Run sqlite integration tests
Start tests
make test-sqlite
Run MySQL integration tests
Setup a MySQL database inside docker
docker run -e MYSQL_DATABASE=test -e MYSQL_ALLOW_EMPTY_PASSWORD=yes -p 3306:3306 --rm --name mysql mysql:latest #(Ctrl-c to stop the database)
Start tests based on the database container
TEST_MYSQL_HOST=localhost:3306 TEST_MYSQL_DBNAME=test?multiStatements=true TEST_MYSQL_USERNAME=root TEST_MYSQL_PASSWORD='' make test-mysql
Run pgsql integration tests
Setup a pgsql database inside docker
docker run -e "POSTGRES_DB=test" -e POSTGRES_PASSWORD=postgres -e POSTGRESQL_FSYNC=off -e POSTGRESQL_EXTRA_FLAGS="-c full_page_writes=off" -p 5432:5432 --rm --name pgsql data.forgejo.org/oci/bitnami/postgresql:16 #(Ctrl-c to stop)
Setup a S3 server inside docker
docker run -e MINIO_ROOT_USER=123456 -e MINIO_ROOT_PASSWORD=12345678 -p 9000:9000 --rm --name minio data.forgejo.org/oci/bitnami/minio:2024.8.17 #(Ctrl-c to stop)
Start tests based on the database container
TEST_PGSQL_HOST=localhost:5432 TEST_PGSQL_DBNAME=test TEST_PGSQL_USERNAME=postgres TEST_PGSQL_PASSWORD=postgres TEST_S3_HOST=localhost:9000 make 'test-pgsql#Test'
Running individual tests
Example command to run GPG test:
For SQLite:
make test-sqlite#GPG
For other databases (replace mysql to pgsql):
TEST_MYSQL_HOST=localhost:1433 TEST_MYSQL_DBNAME=test TEST_MYSQL_USERNAME=sa TEST_MYSQL_PASSWORD=MwantsaSecurePassword1 make test-mysql#GPG
Setting timeouts for declaring long-tests and long-flushes
We appreciate that some testing machines may not be very powerful and the default timeouts for declaring a slow test or a slow clean-up flush may not be appropriate.
You can either:
- Within the test ini file set the following section:
[integration-tests]
SLOW_TEST = 10s ; 10s is the default value
SLOW_FLUSH = 5S ; 5s is the default value
- Set the following environment variables:
GITEA_SLOW_TEST_TIME="10s" GITEA_SLOW_FLUSH_TIME="5s" make test-sqlite
Tips and tricks
If you know noteworthy tests that can act as an inspiration for new tests, please add some details here.