Currently the dropdown will overflow on narrow screens, because it is
aligned on the left side to the button. To prevent this, align the right
side to the button.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13495
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
This PR replaces the existing `skip-to` approach for rendering large diffs with paging over the changeset of a git diff, enabling a more efficient way to render the compare view for PR, compare, and commit views.
## Problem
When a user opens a compare page for a large range of commits, Forgejo calculates the entire diff (potentially multiple times) Which consumes significant CPU time on the server and produces an enormous amount of HTML for the browser to parse and display. At some point the page becomes unusable or fails to load entirely.
The previous `skip-to` approach attempted to mitigate this by allowing the user to jump to a specific file or section within the diff. However, this still required the diff process and prepare the full changeset up to that point. It did not fundamentally bound the amount of work done per request: the server could still spend excessive time calculating the Diff. As a result, `skip-to` was not a reliable solution for very large diffs.
TLDR; `--skip-to` is an output-ordering/presentation option, not a performance optimization. [git docs](https://git-scm.com/docs/diff-options#Documentation/diff-options.txt---skip-tofile)
## Solution
This change introduces paging over the changeset of a git diff. Rather than relying on `skip-to`, the diff is now split into manageable pages. Only a subset of the changed files is fetched, highlighted, and rendered at a time.
### Tests for Go changes
- I added test coverage for Go changes...
- [x] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### 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.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Security features
- [PR](https://codeberg.org/forgejo/forgejo/pulls/12808): <!--number 12808 --><!--line 0 --><!--description ZG9uJ3QgcmVuZGVyIGxhcmdlIGNvbXBhcmUgZGlmZg==-->don't render large compare diff<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12808
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Closesforgejo/forgejo#6133
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes
(can be removed for JavaScript changes)
- 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 ran...
- [x] `make pr-go` before pushing
### 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.
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
NOTE: add Gusted as co-author
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- User Interface bug fixes
- [PR](https://codeberg.org/forgejo/forgejo/pulls/13479): <!--number 13479 --><!--line 0 --><!--description Zml4KHVpKTogYmxhbWUgZGlzcGxheXMgYSBwbGFjZWhvbGRlciBpZiB0aGUgY29tbWl0IG1lc3NhZ2UgaXMgZW1wdHk=-->fix(ui): blame displays a placeholder if the commit message is empty<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13479
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Replace Fomatnic-based menu with a details-based one for better accessibility, less reliance on JS, etc. Of course, none of the features in this menu work without JS, but it's still a good change for for accessibility, UI consistency and phasing Fomantic out.
## Preview
|Before|After|
|-|-|
|||
Tippy:
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10830
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
This PR moves the release assets above the code archives on the releases page, as the assets are likely what the user is looking for compared to the code archive.
resolves#12534.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13038
Reviewed-by: limiting-factor <limiting-factor@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Continuation of #10598Closes#7254
Implement repo granular watch selection
I adopted a lot of the frontend from #10598 while redoing the entire back-end. I propose this new model:
- Remove the WatchMode enum.
- Add the WatchSelection struct, which represents the granular selection. Notice that there is no `watching` bool. I tried very hard to keep the structure as simple and redundancy-free as possible. Therefore, people not watching a repo at all either don't have a watch record or one with an entirely unselected WatchSelection struct.
- Add the WatchSource enum. It replaces the WatchMode enum and has a single purpose: determine whether a watch was explicitly or automatically initiated.
Notice that replacing this
```go
And("`watch`.mode<>?", WatchModeDont).
```
with this is correct:
```go
And(
builder.Or(
builder.Eq{"`watch`.watch_selection_issues": true},
builder.Eq{"`watch`.watch_selection_pull_requests": true},
builder.Eq{"`watch`.watch_selection_releases": true},
),
).
```
That's because there are four modes: dont, none, auto and normal. When `<>` with dont, we look for auto and normal, because there are no records with none. Therefore, the old code looks for records that indicate watching. The code I replaced this with does so, too, just more granular.
Also notice that I've prepared a future `user preset` in a few places. See below for a little more info on that.
## Next PR
I plan to continue working on this. I want to implement a `user preset` option. The user sets that `user preset` in her settings and may use them in any repo.
<details>
- rename account settings to account and notifications
- user preset (always use this preset for newly accessible repos (according to AutoWatchOnChanges and AutoWatchNewRepos))
</details>
## Further PRs
- make api able to granular watch
- move (email) notifications to new notifications tab
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10927
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
This will allow us to enforce RTL-friendly logical CSS properties in the go template files.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13216
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Close#13250
ExtraLinesCount was not send to reply template
### Tests for Go changes
- I added test coverage for Go changes...
- [X] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [X] `make pr-go` before pushing
### Documentation
- [X] I did not document these changes and I do not expect someone else to do it.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13258
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Fixesforgejo/forgejo#12951
The changes are made to the following template files:
- on the repo star/unstar button
- on the repo watch/unwatch button
- on the issue notification button
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12976
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
This is a proof of concept for replacing Formatic's buggy dropdown with
something else. There are a bunch of open gitea issues on github
discussing getting rid of Fomantic.
Tested in Firefox/Chrome. Attached screenshots are before/after. The one with the input focused in orange, and tighter letter spacing, is after.
If this is merged I plan to move the other selectors off of Fomantic.
Alternative to https://codeberg.org/forgejo/forgejo/pulls/12731, also fixes#10118
Signed-off-by: Markus Unterwaditzer <markus-tarpit+git@unterwaditzer.net>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12736
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Any job with `permissions:`, and all jobs in a workflow with `permissions:`, will display a warning at the top of the Actions screen indicating that this field is not supported by Forgejo.
### Tests for Go changes
- I added test coverage for Go changes...
- [x] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### Tests for JavaScript changes
- I added test coverage for JavaScript changes...
- [x] 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.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13164
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Introduce the capability to manually prioritize individual workflow runs. If possible, manually prioritized workflow runs will be run before all others. If multiple workflow runs have been prioritized manually, they will be run in their order of arrival, not in the order they have been prioritized manually.
Workflow run prioritization is best-effort, no matter whether a workflow run has been (de-)prioritized manually or by a prioritization algorithm. That means that it usually has an effect, but it's not guaranteed to have one.
Workflow run prioritization is performed by implementations of `RunPrioritizationStrategy`. Currently, only one implementation exists: first in, first out, with the option to manually mark individual workflow runs as prioritized. It is possible to add more strategies in the future and make them selectable in the user interface per repository.
Implementations of `RunPrioritizationStrategy` can only influence the ordering of `ActionRunJob`s by altering the priority of the `ActionRun` they belong to. That is a conscious choice to reduce the risks of deadlocks or other potentially weird behaviour that would be hard to debug. The priority of `ActionRun`s that are already running is not recalculated for the same reason.
The run priority cannot be observed by external systems because it is neither exposed in the HTTP API nor to webhook listeners. That limitation can be alleviated in future versions.
See also https://codeberg.org/forgejo/forgejo/issues/12830 and https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/92.
### Tests for Go changes
- I added test coverage for Go changes...
- [x] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### 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/13045
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Multiple fixes squashed into one PR for simplicity. See individual commit messages in the PR for details
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12843
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
This PR pertains to the client-side validation of the Website input on user, repo, and org profiles. #12962 extends `[service].VALID_SITE_URL_SCHEMES` to cover Website fields on repo and org profiles, where before that config key only applied to the one on user profiles. If that change merges, it will then be possible to construct an HTML [`pattern`](https://developer.mozilla.org/docs/Web/HTML/Reference/Elements/input#pattern) attribute for general use on any Website form input that the server validates this way, thus enabling browsers to catch errors early relating to URL scheme confusion.
This PR (1) introduces such a `pattern` attribute, and (2) adds a new UI note to make clear to users which URL schemes are permitted. This change helps explain the browser's otherwise cryptic error messages regarding pattern mismatch, while also letting users know what URI schemes the Forgejo instance supports as Website links (e.g. gemini:// URLs).
This MUST NOT merge before #12962. To do so would introduce a regression wherein the UI may suggest and validate a different set of allowed URL schemes than the server actually permits.
See also #5519
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12991
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Closes https://codeberg.org/forgejo/forgejo/issues/6093
This PR adds support for **multi-line review comments** on pull requests, allowing reviewers to select a range of lines in diffs instead of only a single line — similar to GitHub's implementation.
### Tests for Go changes
- I added test coverage for Go changes...
- [X] in their respective `*_test.go` for unit tests.
- [X] `make pr-go` before pushing
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12582
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
I removed the empty `p` elements for accessibility as mentioned in this https://codeberg.org/forgejo/forgejo/pulls/12786#issuecomment-16247117. I also adjusted the spacing for the "reference" text with the divider to have the copy button have the same spacing as other buttons.
## Testing
Navigate to an issue and observe the spacing of the time tracker, reference and dependencies sections.
<table style="width:100%">
<tr>
<td>Before</td>
<td>After</td>
</tr>
<tr>
<td><img width="250" src="/attachments/a4e14050-1d14-457c-9d4f-ec9ac1ae3bcc" /></td>
<td><img width="250" src="/attachments/3ab4445c-9f14-49d7-ac77-a7d69e914e58" /></td>
</tr>
</table>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12864
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Some minor changes: coherent distances between heading and descriptions, drop a divider between time tracking related sections.
### Test
1. Go to an issue, add some time tracking and potentially dependencies.
2. Observe improved distances with a user with and once with a user without write permission.
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/12786
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
This
1. hides the “New issue” button, which currently leads to a 404 page, because it is not useful to have it, e.g., here: https://code.forgejo.org/forgejo/act/issues/169
2. removes the UI ability on projects in archived repos to move around issues and project columns. When a user performs such an action, currently it is shown as it were successful, but actually all requests lead to 404s without warning.
3. hides the hints for synching a fork or creating a pull request for recently pushed branches (which again would lead to 404s)
4. hides the branch selector (only shows the branch) on single issue/PR pages, which is disfunctional on archived repos
Thus, both these changes do not change anything related to what happens to issues or projects in archived repos, but only reduces 404 errors.
I don’t think this needs to be tested more than manually.
## Test
Create first a repository with at least **one issue** in **one project** and edit a file by creating a **new branch**. Then, perform following actions, once in the state where the repository is normal and once when it is archived:
action|unarchived|archived
---|---|---
\1. go to the issue|“New issue” button functional|“New issue” button removed
\2. click on the branch selector|menu opens|menu is now disabled and shows the branch
\3. go to the project|“New issue” button functional|“New issue” button removed
\4. try to move around columns|modifies columns|not possible anymore
\5. try to move around the issue|modifies issue location|not possible anymore
\6. go to the code view|see hint "You pushed …"|do not see this hint anymore
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12773
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
For the same reason the merge box is displayed when the user can delete the branch from which the pull request was proposed, the trust panel must be displayed when runs are waiting approval, either for information or to approve/deny runs from untrusted users.
Closesforgejo/forgejo#12576
---
Note that since this is a followup of https://codeberg.org/forgejo/forgejo/pulls/12704/files and it has not yet been released, there is no need for a mention in the release notes.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes
(can be removed for JavaScript changes)
- 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 ran...
- [x] `make pr-go` before pushing
### 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/12785
Reviewed-by: Robert Wolff <mahlzahn@posteo.de>
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
When the status of a user makes it implicitly trusted to run actions (for instance when it becomes a member of the Owners team of an organization), the runs that were blocked before they became trusted will need to be approved or denied.
The trust management panel was not displayed if the poster of the pull request was trusted. It is now displayed regardless of the current trust status of the user.
Closesforgejo/forgejo#12811
---
## Alternative implementation
An alternative implementation would be to approve all pending runs whenever the trust status of a user changes. That would require that change to happen when the user joins a team with permissions to run actions, becomes an admin, a collaborator to a repository with write access or when a repository ownership is transferred to an organization where the user already has such rights.
Such an implementation would save the effort of manually taking care of the runs pending approval for the now trusted user. But it would also be fragile to maintain because it would need a complete inventory of all the ways a user can become trusted. Or some kind of notification triggered whenever such an event happens, which is not currently in place.
Since this is a rare case and the manual operation is simple, I think the easiest fix consisting of showing the trust panel regardless of the trust status of the user is acceptable.
## Lingering rows in `ActionUser`
If a newly trusted user is explicitly always trusted **after** being implicitly trusted, a row is created in `ActionUser`. But the `Revoke` button will never show, because the user is now implicitly trusted. This leaves a lingering row in the `ActionUser` table. Such a row will be [removed](!9397 (commit e41bcf5048)) eventually and not clutter the table.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes
(can be removed for JavaScript changes)
- 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 ran...
- [x] `make pr-go` before pushing
### 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-->
- User Interface bug fixes
- [PR](https://codeberg.org/forgejo/forgejo/pulls/12812): <!--number 12812 --><!--line 0 --><!--description Zml4OiBzaG93IHRoZSBhY3Rpb25zIHRydXN0IG1hbmFnZW1lbnQgcGFuZWwgd2hlbiBydW5zIGZyb20gdHJ1c3RlZCB1c2VycyBhcmUgcGVuZGluZyBhcHByb3ZhbA==-->fix: show the actions trust management panel when runs from trusted users are pending approval<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12812
Reviewed-by: Robert Wolff <mahlzahn@posteo.de>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Following the feedback in #12565, this adds a hint to the units page when the "Enable more" hint is enabled:
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12747
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Robert Wolff <mahlzahn@posteo.de>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
It is possible for a user that is not trusted to run Forgejo Actions workflows on a repository to act on a pull request and trigger a workflow after it is merged or closed. For instance by modifying the title of the pull request or setting a label.
Closesforgejo/forgejo#12576
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes
(can be removed for JavaScript changes)
- 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 ran...
- [x] `make pr-go` before pushing
### 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.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- User Interface bug fixes
- [PR](https://codeberg.org/forgejo/forgejo/pulls/12704): <!--number 12704 --><!--line 0 --><!--description ZGlzcGxheSB0aGUgYWN0aW9ucyB0cnVzdCBtYW5hZ2VtZW50IHBhbmVsIG9uIG1lcmdlZCBhbmQgY2xvc2VkIHB1bGwgcmVxdWVzdHM=-->display the actions trust management panel on merged and closed pull requests<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12704
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
This fixes#12548. I used the `RenderRefIssueTitle` function so it wouldn't create issue or PR links from #<number> strings.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12644
Reviewed-by: Robert Wolff <mahlzahn@posteo.de>
When it was introduced the route did receive for which entries it should get the last commit for. It was refactored in 1e29bccddb to HTMX and now simply gets the last commit for all entries.
In the spirit of using the correct HTTP methods, switch it to GET.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12670
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
A concern has been raised to the security team that Forgejo users can be confused by the visibility of packages in Forgejo being linked to the owner of the package, and not the repository that a package may be linked to. While future feature requests may change how package visibility works, an immediately actionable response is to ensure that this is clearer to end-users.
This PR adds a warning on the Settings -> Unit page of a private repository, and the Packages tab of a private repository, if the owner of the repository is public. It also renames the unit "Enable repository package registry" to "Enable package linking", to better reflect the fact that enabling packages on a repository does not create some repository-level registry.
**Before**:
**After**:
**On repository's Packages tab**:
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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).
### 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.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12627
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
A separate commit status is introduced for skipped checks. That enables marking them as such in the UI instead of successful, which could be misleading.
Resolves https://codeberg.org/forgejo/forgejo/issues/10138.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes
(can be removed for JavaScript changes)
- I added test coverage for Go changes...
- [x] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### Tests for JavaScript changes
(can be removed for Go changes)
- 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/12606
Reviewed-by: Cyborus <cyborus@disroot.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Add the ability to remove workflow runs, either using the UI or the HTTP API. Workflow runs can only be removed once a workflow run has completed. For security reasons, only a repository administrator or a token with `write:repository` permissions can remove runs.
Resolves https://codeberg.org/forgejo/forgejo/issues/2184.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes
(can be removed for JavaScript changes)
- I added test coverage for Go changes...
- [x] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### Tests for JavaScript changes
(can be removed for Go changes)
- 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-->
- Features
- [PR](https://codeberg.org/forgejo/forgejo/pulls/12478): <!--number 12478 --><!--line 0 --><!--description bWFrZSBpdCBwb3NzaWJsZSB0byByZW1vdmUgd29ya2Zsb3cgcnVucw==-->make it possible to remove workflow runs<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12478
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Fairly new to Forgejo but I just ran into this when trying to create a couple repositories.
I noticed that the input field for the repository name in several areas of the UI is prone to have annoying auto-capitalization, spellchecking and other browser features which try to correct the user input.
I as a user would like to not have the browser interfere with my input especially in dialogs where I want to have something "custom".
For fields where the repo name is used to validate an action (Danger Zone) this is even more frustrating.
So, to me, this is a quality of live improvement fix.
I checked the docs for these three attributes and none of them seem to have a negative side effect for the user:
1. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/autocorrect
2. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/autocapitalize
3. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/spellcheck
## List of URLs where this applies:
1. `/repo/migrate`
2. `/repo/create`
3. `/<user>/<repo slug>/settings`
4. In general things in the "Danger zone" section where the repo name is used to validate the action
5. …
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12506
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Allows user to assign organization projects to their new issues, using the project sidebar selector, even when repository's projects are disabled.
Moreover, the project sidebar selector is now hidden if no projects (repository-wide + organization-wide) are available.
Fixesforgejo/forgejo#5666
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/7999
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Having tooltip only for `lfs_pointers.accessible` is fine in English, but not in other languages. For other languages the text is truncated.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12139
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
This idea is perhaps a bit more far-fetched. It implements the ability in `lint-locale-usage` to basically fully handle "printf" invocations by transforming format strings to regexps when "%" wildcards are present.
Currently, it doesn't cache the transformation from format string to compiled regex because this doesn't make a performance difference (yet), given that most of these wildcards are only hit once or twice.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12013
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Unintentionally fixesforgejo/forgejo#11812 per tip https://codeberg.org/forgejo/forgejo/pulls/12232#issuecomment-13580345
---
This is a second attempt to fix https://codeberg.org/forgejo/forgejo/issues/11116. The [first attempt](https://codeberg.org/forgejo/forgejo/pulls/11846) introduced a [regression](https://codeberg.org/forgejo/forgejo/issues/12082) and needed to be [reverted](https://codeberg.org/forgejo/forgejo/pulls/12088).
What's different about this attempt is that several days of extra work have been invested in amending the CSS to ensure that no visual changes slip through as a side-effect of the structural changes to the HTML. This was surprisingly challenging, and I documented much of the journey in https://codeberg.org/henrycatalinismith/forgejo/issues/1.
In summary, the existing version of the "latest commit" row leans heavily on global styles that are universally applied to all `thead` elements inside `table` elements with the `ui` and `table` classes. The nature of the structural HTML changes necessary to fix the accessibility bug (this row can't be inside `thead`) is such that those universal styles no longer apply to this element and must be duplicated into new element-specific styles. Similarly, existing styles applying to non-`thead` table content has unwanted effects on this element once it moves into the `tbody` which needed to be counteracted.
The original PR already lays out the accessibility impact of this pull request in a good amount of details and so instead I'm going to use the space here to focus on comparing the visuals in the `forgejo` branch with those in this PR. There follow a few pretty boring identical before & after screenshots that are pixel-for-pixel identical with each other. I don't think you'll be able to spot any bugs by glancing at these and am more sharing them to provide an insight into where my attention has been during testing: the 380px wide mobile viewport, a larger desktop viewport, and the "commit message too long to fit in the available space" case. If you know of other troublesome cases for this code that aren't covered by what you see in these images then that could be a good thing to explore here.
Before | After
-|-
 | 
 | 
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12232
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
While developing tests for #12092, I came across a case where making a comment on a single-commit doesn't include the correct diff for the comment. This is because code comment placement occurs between the PR's base and the commit being viewed, but, that diff could be different from the commit's parent to the commit, which is what is being viewed on a single-commit diff.
Similar to #12055, this PR changes code comments to be more precise in their diff generation by providing the backend with both the base commit (`before_commit_id`) and head commit (`after_commit_id`) currently being viewed. As a result, the diffs attached to comments should exactly match the diffs being viewed by the user when the comment was placed.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes
- 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 ran...
- [x] `make pr-go` before pushing
### 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.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12107
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Fixes https://codeberg.org/forgejo/forgejo/issues/12082 by reverting commit dd968f147d.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes
(can be removed for JavaScript changes)
- 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 ran...
- [ ] `make pr-go` before pushing
### Tests for JavaScript changes
(can be removed for Go changes)
- 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.
- [ ] 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.
- [ ] 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/12088
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
When performing `git blame` to identify the commit that a line of code came from, limit the blame to the commit that is currently being viewed in the UI. Before this change, the blame always occurred on the current head of the PR, causing these problems:
- When you click ➕ to load the comment form, the form that is dynamically loaded would have it's commit field pulled from the current PR head. That may not actually reflect the code that you were viewing at the time you authored the comment -- it could be a newer commit that occurred by the author while you were reviewing.
- When viewing a specific commit within a PR and leaving a comment, the blame would occur from the head -- if the file was changed in a later commit and the line-of-code moved up or down, the comment would be misplaced.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes
- 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 ran...
- [ ] `make pr-go` before pushing
### 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.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Bug fixes
- [PR](https://codeberg.org/forgejo/forgejo/pulls/12055): <!--number 12055 --><!--line 0 --><!--description d2hlbiByZXZpZXdpbmcgaW4gUFJzLCBtYWtlIGNvbW1lbnRzIHJlbGF0aXZlIHRvIHRoZSB2aXNpYmxlIGNvZGUncyBjb21taXQ=-->when reviewing in PRs, make comments relative to the visible code's commit<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12055
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Fixes#6438
When a protected branch requires signed commits and no signing key is available, fast-forward-only merges should still be allowed because they do not create a new commit.
This patch applies signing checks by merge behaviour/style instead of one global gate:
- pass `mergeStyle` through `CheckPullMergeable(...)` in web/API/automerge paths
- require signing for commit-creating styles (`merge`, `rebase`, `rebase-merge`, `squash`)
- bypass signing precheck only for `fast-forward-only`
- align merge UI options with backend behaviour so signing-dependent styles are unavailable when signing cannot happen
- add Go unit tests for merge-style signing requirements
- add frontend unit coverage for the no-allowed-merge-styles guard
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11403
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: abdo <dev@abdo.wtf>
Co-committed-by: abdo <dev@abdo.wtf>
Fixes https://codeberg.org/forgejo/forgejo/issues/11880.
Adding `hx-on::after-settle="this.querySelector('button').focus()"` restores focus after the content has been swapped and the DOM has been setled. I tried `hx-on::after-swap` first since it's mentioned more often in https://github.com/bigskysoftware/htmx/issues/1869, but it didn't work.
The demo attached in `focus.mp4` runs through a series of repeated clicks on both buttons. You can hear the screen reader announce the button's new label when focus is restored.
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [ ] 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/11932
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
https://codeberg.org/forgejo/forgejo/issues/11116
To understand the impact of this you really need to listen to the before and after screen recordings attached. https://codeberg.org/forgejo/forgejo/issues/11116 is a really great bug report, and I was surprised by how disorienting this actually was when testing manually compared to my expectation after reading the issue. This is an impactful improvement!
This is my first time adding new translation strings. Excited to learn more about that if I've guessed wrong about how to do it.
To summarise, what we're doing here is as follows.
1. Address the core issue by changing the existing `<th>` elements to `<td>` so that screen readers stop semantically associating them with each row and reading them out for every table cell.
2. Replace them with real `<th>` elements that communicate the true semantic role of each column.
3. Add a `<caption>`. This serves a dual purpose: it gives the table an accessible name which improves the navigability of the page, and it gives us a place to explain to the user that the first row of the table is a little bit different because it's the latest commit rather than a file in the repo.
4. Visually hide the new caption and headings so that only screen reader users get them.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for JavaScript changes
- 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.
- [ ] 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/11846
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
Fixes#9629.
New pull mirrors have credentials stored encrypted in the database, the same as push mirrors, rather than in the repository's `config` file. `git fetch` on the pull mirror is updated to use the credential store. Pull mirrors will have their credentials migrated to the encrypted storage in the database as they're synced or otherwise accessed via the web UI.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes
- 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 ran...
- [x] `make pr-go` before pushing
### 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.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11909
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
This copy button on the pull request page lacks an accessible name. You can hear the screen reader announce it as just "button" in the screen recording `button.mp4`, and then hear the amended version in `copy.mp4` where it's announced as "copy, button".
The most relevant WCAG success criteria here is [1.1.1 Non-text content](https://www.w3.org/WAI/WCAG21/Understanding/non-text-content.html).
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [ ] 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/11895
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
* migrate 17 strings related to repository migrations from INI to JSON
* changed templates to get rid of unhelpful prefix `repo`
* migrate 4 strings related to counters
* also changed templates to get rid of `repo`, but it had to be done anyway to use `TrPluralString`
* Unhardcode the header on migraiton type selector page, which I haven't noticed in https://codeberg.org/forgejo/forgejo/pulls/6795 or in two other PRs I did on this template since
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11879
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Fixes https://codeberg.org/forgejo/forgejo/issues/6621.
The attached screen recording `before.mp4` demos the problem as described by https://codeberg.org/forgejo/forgejo/issues/6621. And `after.mp4` is the fixed version.
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [ ] 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/11878
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
