The module calling `log.Fatal()` (which terminates the process) prevents the calling function to enrich the error message with vital information allowing the user to track down problematic configuration directives. Also this was impeding unit tests.
One such case is where the path to the specified key can not be created, as demonstrated in the test case. Here the error message is:
```
Error while loading or creating JWT key: Error generating private key ...: mkdir ...: permission denied
```
`log.Fatal()` is kept for `f.Close()` errors which indicate much more severe but very rare underlying issues. Handling these would require broader changes.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11066
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
Fixes#11030.
When a `strategy.matrix` needs to be evaluated on the output of another job, it can become evaluated into an empty set of jobs. In this case, and assuming no other jobs in the run are active, the run should reach a settled state. The logic to check the other jobs in the run and determine if this state has been hit needs to be explicitly added to the job emitter.
To accomplish this change, this action run state logic was extracted out of `UpdateRunJobWithoutNotification` where it could be reused.
## 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...
- [x] in their respective `*_test.go` for unit tests.
- [ ] 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
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
*The decision if the pull request will be shown in the release notes is up to the mergers / release team.*
The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11063
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
- In order to avoid a database locked message, you either need shared
cache or WAL. Shared cache was disabled in as its deprecrated and could
cause more good than trouble. Enable WAL by default, it's only
non-desirable in very narrow and select situations (NFS filesystem
situation) and is otherwise safe as default.
- Resolvesforgejo/forgejo#10900
Docs: forgejo/docs!1717
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11059
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Fixes#10881
Call the proper function for each repository the user watches, so adjusting the watch count can be done properly.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10882
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: christopher-besch <mail@chris-besch.com>
Co-committed-by: christopher-besch <mail@chris-besch.com>
This PR fixes a number of typos throughout the entire repository. Running https://github.com/crate-ci/typos and then changing all occurrences that I naively deemed "safe enough".
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10753
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Christoph Mewes <christoph@kubermatic.com>
Co-committed-by: Christoph Mewes <christoph@kubermatic.com>
This PR is in preparation of, but independent of, an upcoming suggestion for a feature addition:
* The first commit moves a tiny bit of logic into a separate function to prepare for extension of that logic, avoiding duplication
* The second commit moves checking for disabled registrations earlier, which, I think, has merits in terms of performance and resilience (hopefully not significant, but who knows?)
* The third commit adds simple unit tests for SignUp() and SignUpPost() to avoid the long-ish roundtrip over integration tests
* The forth commit introduces `ctx.Data["DisableRegistrationReason"]` for the signup template to use as the reason printed if `.DisableRegistration` to prepare for other reasons to be added
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10915
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
Forgejo supports disabling features for users with the configuration
options `USER_DISABLED_FEATURES` and `EXTERNAL_USER_DISABLE_FEATURES`.
Add `manage_password` that prevents users from configuring passwords.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10541
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: hwipl <hwipl@noreply.codeberg.org>
Co-committed-by: hwipl <hwipl@noreply.codeberg.org>
Followup to https://codeberg.org/forgejo/forgejo/pulls/6154
en-US:
two days ago -> 2 days ago
two weeks ago -> 2 weeks ago
two months ago -> 2 months ago
two years ago -> 2 years ago
Other locales still require changes to ensure
that the relative time numbering is consistent.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10691
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: lily <lesson085@gmail.com>
Co-committed-by: lily <lesson085@gmail.com>
For the previous code with the Page attribute present in
ListCursorOptions for page 1, github would not return an "After" cursor,
such that the request for page 2 would request what effectively is the
content of page 1 a second time.
This would lead to an attempt to insert the same issues twice.
Note that this is not the only reason why this can happen with the
current code base.
We fix this particular issue by not using the Page attribute so github
does return an "After" cursor.
Fixes#10794
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10798
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
A template should not get (easy) access to a full signing key to prevent accidents.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10967
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
This is a successor to #10805, which simply did not work. It is also much simpler and basically a one line change to enable an existing feature in [go-github](https://github.com/google/go-github).
Fixes#10845
With this fix and #10798 in place, a migration of a repo with ~3K issues and ~1.3k pull requests finally completed successfully.
## Patch
We use SleepUntilPrimaryRateLimitResetWhenRateLimited to instruct the go-github code to wait until the retry time and retry the request when the primary rate limit gets hit.
## Test case
TestGitHubDownloadRepo() has been modified such that 403 rate limit errors are injected every 7 requests with a retry time of one second, resulting in the rate limit condition being hit twice with the current tests. The test case confirms that the migration code itself is in fact unaffected by the rate limit being hit.
## Scope
This change does not affect secondary rate limits.
If the server is restarted during the wait for the rate limit refresh, the migration likely still fails when retried, because inserts for already present database objects will be attempted.
This approach effectively puts the task's goroutine to sleep until the retry time, which implies that the respective resources stay allocated.
A better approach might be to add the necessary infrastructure to support restarts of migration tasks at a later time, but this is much more involved, because the migration state would need to be saved and/or re-created based on already pulled data. This would also require adding support for database upserts.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10846
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
It has always been largely used for showcasing UI elements but that name didn't work too well for it.
Testing:
Some of existing tests depend on these pages, making it redundant to create extra tests.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11019
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
I've been reading through the watch model code and found that the `isWrite` flag is dead code — it isn't used anywhere. To be honest I don't see why we should need that anyways. Therefore, I deleted it.
Also I've added some comments for the `WatchMode`. It took me quite some time to figure out why there are four options.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10880
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: christopher-besch <mail@chris-besch.com>
Co-committed-by: christopher-besch <mail@chris-besch.com>
The two commits in this PR fix test cases which did not work as intended, because `require.Errorf()` was used where `require.ErrorContains()` was intended.
The former formats the error output by the test itself when failing, while the latter is to expect the tested error to contain some expected string.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11035
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
Related to #11035, this test case used `require.Errorf()` where it could use `require.Error()` to make it clear that this is not a case of confusion with `require.ErrorContains()`
The other cases in the same function already use `require.Error()`, so this clearly looks like a consistency glitch.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11037
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
Regression of forgejo/forgejo!9587
`git-diff` will always find renames because it is implied by the `diff.renames` configuration option. Specify `--find-renames` to detect renames again.
Resolvesforgejo/forgejo#11032
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11038
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
The indexer previously used a `camelcase` filter which could be problamatic for certain queries.
This commit removes the faulty filter for bleve, matching the behaviour of the database "indexer".
closes!10997
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11022
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Co-committed-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Make it possible to filter action runs returned by `/api/v1/repos/andreas/test/actions/runs` by Git reference.
Resolves https://codeberg.org/forgejo/forgejo/issues/10874.
## 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
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
*The decision if the pull request will be shown in the release notes is up to the mergers / release team.*
The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11013
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Found while working on https://codeberg.org/forgejo/forgejo/pulls/10798#issuecomment-10083846: The symptom was that the go-github client never returned a `resp.After`, so I tracked down the root cause, which was that, with the mocked http server ...
Mocked headers never reached the calling client, because w.WriteHeader()
was called before the headers were set in the response.
Fix by moving w.WriteHeader() to the right place just before w.Write(),
which writes the body.
Test added which fails without the fix and succeeds with it.
### Tests
- I added test coverage for Go changes...
- [X] in their respective `*_test.go` for unit tests.
- [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
### 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
- [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [X] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11007
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
This PR makes two changes.
**First**, it removes the ability for Forgejo to rewrite ssh authorized_keys during startup. Forgejo previously checked if the application path or config file path had changed from that which is recorded in its database. If either has changed, it would rewrite the SSH `authorized_keys` file, as those paths are embedded into that file. The problem is that if a new installation runs the app and goes through a standard init procedure, it will clobber ~/.ssh/authorized_keys which is a disruptive mistake.
Instead, Forgejo will proceed to ssh initialization, and due to the change in #10010 the incorrect application path or config file path will result in a fatal server error that the administrator must resolve. Disabling SSH is added as a plausible option for how to resolve that fatal error.
**Second**, the interactive install UI has been modified to detect this error before the installation proceeds. If a user is attempting to install Forgejo with SSH, and they have an existing `~/.ssh/authorized_keys` file with keys present in it, the installation will fail with an error advising them to use a separate Forgejo user or to disable SSH. (More options are possible to fix this problem, but these are the obvious solutions.)
Fixes#10942.
Manually tested. Without the install process change, Forgejo behaves like this:
- Configure a typical end-user `~/.ssh/authorized_keys` file with normal keys
- Run through a Forgejo initialization process on a new database; run with SQLite, add a new administrator account during the init process.
- After initialization, Forgejo will restart and encounter a fatal error:
```
2026/01/20 10:11:24 routers/init.go:84:syncAppConfForGit() [I] AppPath changed from '' to '/home/mfenniak/Dev/forgejo/forgejo'
2026/01/20 10:11:24 routers/init.go:89:syncAppConfForGit() [I] CustomConf changed from '' to '/home/mfenniak/Dev/forgejo/custom/conf/app.ini'
2026/01/20 10:11:24 routers/init.go:95:syncAppConfForGit() [I] re-sync repository hooks ...
2026/01/20 10:11:24 ...er/issues/indexer.go:155:func2() [I] Issue Indexer Initialization took 9.858336ms
2026/01/20 10:11:24 modules/ssh/init.go:86:Init() [F] An unexpected ssh public key was discovered. Forgejo will shutdown to require this to be fixed. Fix by either:
Option 1: Delete the file /home/mfenniak/.ssh/authorized_keys, and Forgejo will recreate it with only expected ssh public keys.
Option 2: Permit unexpected keys by setting [server].SSH_ALLOW_UNEXPECTED_AUTHORIZED_KEYS=true in Forgejo's config file.
Option 3: If unused, disable SSH support by setting [server].DISABLE_SSH=true in Forgejo's config file.
Unexpected key on line 1 of /home/mfenniak/.ssh/authorized_keys
Unexpected key on line 2 of /home/mfenniak/.ssh/authorized_keys
Unexpected key on line 3 of /home/mfenniak/.ssh/authorized_keys
Unexpected key on line 4 of /home/mfenniak/.ssh/authorized_keys
```
With the install process change, the above error screenshot occurs instead.
## 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.
- [ ] 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
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
*The decision if the pull request will be shown in the release notes is up to the mergers / release team.*
The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Bug fixes
- [PR](https://codeberg.org/forgejo/forgejo/pulls/10948): <!--number 10948 --><!--line 0 --><!--description ZG9uJ3QgY2xvYmJlciBhdXRob3JpemVkX2tleXMgZmlsZSBkdXJpbmcgaW5zdGFsbGF0aW9u-->don't clobber authorized_keys file during installation<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10948
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Forgejo organisations can have multiple owners. In issue or PR discussions, the tooltip for the "Owner" role should not imply that a repository has a single owner. Therefore, I am proposing that it says "an owner" instead of "the owner".
One choose to keep the tooltip with its current wording for repositories owned by an individual (instead of an organization), but the new tooltip remains correct even if there happens to be a single owner, and I don't think the wording difference warrants a runtime check.
#### Before (on Codeberg)
#### After (on local instance)
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11004
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Antonin Delpeuch <antonin@delpeuch.eu>
Co-committed-by: Antonin Delpeuch <antonin@delpeuch.eu>
The custom styles for tippy-enabled menus had too broad selectors, conflicting with styles of other .item elements in tippy boxes.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10969
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
While reviewing cpuprofiles of #10985, I noticed a bunch of slice-grows within this function.
Instead of `io.ReadAll` (which does not know the size in advance), use `fs.ReadFile`, which will perform correctly-sized allocations.
### Tests
This function is already covered by tests in `modules/assetfs/layered_test.go`
### 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
- [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
*The decision if the pull request will be shown in the release notes is up to the mergers / release team.*
The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10987
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: oliverpool <git@olivier.pfad.fr>
Co-committed-by: oliverpool <git@olivier.pfad.fr>
Polish a glitch from #10481
(kinda sad to let go of such a cute name)
### Checklist
* no tests to change
* no docs to change
* not relevant for release notes
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10966
Reviewed-by: Lucas <sclu1034@noreply.codeberg.org>
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
- `CodeSearchMode` should now be set when keyword is empty
- The default value for search mode should be exact, use fuzzy ONLY when fuzziness is enabled in settings
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10964
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Co-committed-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
* Separate documentation about the workflow for better attention. I could imagine that it was not read by everyone, since it was after the trivial 'Please write in English' instructions.
* Improve explanations about the workflow, expectations and next steps.
* Explicitly mark the Enhancement template to be mostly for contributors.
* Disable blank issues. I could not really identify any recent usage of it that was legitimate.
* Improve instructions about which details to share about the own Forgejo usage.
* Explicitly state in the enhancement template that only issue references should go in there, not noise.
* Create a placeholder in problem template to add references to potential solutions later.
I hope this resolves some of the issues observed with the new workflow and improves the quality of submitted reports. Also addresses the feedback already received in https://codeberg.org/forgejo/user-research/issues/71
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10847
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Otto Richter <otto@codeberg.org>
Co-committed-by: Otto Richter <otto@codeberg.org>
## Summary
Currently, on `{INSTANCE_URL}/admin/config`, the "Disable router log" indicator is completely meaningless, as nothing is assigned to `ctx.Data["DisableRouterLog"]` in [`routers/web/admin/config.go`](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/routers/web/admin/config.go#L121).
This makes the indicator useful without changing any Go code by querying the `Loggers` item that has already been dumped to the context.
Some pictures :)
---
### Before (always)
### After (with default log config)
### After (with `LOGGER_ROUTER_MODE` set to empty)
---
## 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
As far as I can tell, there aren't tests for TMPL template rendering, if I have overlooked them I'll be happy to add.
- I added test coverage for Go changes...
- [ ] in their respective `*_test.go` for unit tests.
- [ ] 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 don't really mind)
- [x] 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/10356
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: avery <avery@catpowered.net>
Co-committed-by: avery <avery@catpowered.net>
