Confine the search menu to be at most the width of the page, or 80% of
the viewport width, whichever is smaller. To do this, introduce a new
`--container-width` variable for the descendant elements of
`.ui.container` to be able to access.
Also update the relevant e2e test: add a long 'lorem ipsum' page, add a
search for it, parameterize the width.
Replace wiki page filenames with page titles in the search results,
fixing the problem with them showing unreadable URI-encoded names.
(cherry picked from commit fc31fa0eeb)
This change does not bring the desired benefit, because the button is
reinitialized from a Vue component once loaded, overriding this change
and causing a visual glitch upon page load (the button is moving its
position).
See the comment:
> this code must match the code in BranchTagSelector.vue
This button is also used in other places such as the release list where
the additional margin does not fit well. As such, this needs a new
solution.
This reverts commit 18cad9d342.
(cherry picked from commit 04e2e1510d)
- Don't double escape the 'Delete branch "$BRANCH"' text. `Locale.Tr`
escapes the argument already and Vue does too by default.
- Let Vue escape the text and add a unit test ensuring that it escapes.
- Resolves#5582
(cherry picked from commit 8c8b31f304)
## 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
- [ ] I do not want this change to show in the release notes.
- [ ] 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.
Co-authored-by: Ehsan Shirvanian <ehsan@duck.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/5503
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: ehshi <ehshi@noreply.codeberg.org>
Co-committed-by: ehshi <ehshi@noreply.codeberg.org>
(cherry picked from commit 82b1ab56de)
Avoids the use of HTMX on milestone assignment within a New Issue form.
The New Issue form doesn't have an issue ID to send to a milestone change URL,
which the backend expects in order to construct a proper reply. The frontend
template was also not built to use the new HTMX response. This resulted in a
backend error and a large warning whenever anyone tried to set a milestone
from within the New Issue form (new pull requests were also affected), rather
than from a View Issue page.
This introduces a new parameter into the `issue/milestone/select_menu`
template, "NewIssuePage".
When unset, the template produces the same results as before. Selection uses
`hx-post` to notify the server immediately, using the updated htmx fragment
from the reply.
When set to a truthy value, the old style of form is used. Selection uses
`data-id` and `data-href` to update the selected milestone locally, via
`selectItem` in `repo-legacy.js`, recreating the selected element and updating
the hidden form value.
Fixes#5176.
Part of #27700
Removes all URLs from translation strings to easy up changing them in
the future and to exclude people injecting malicious URLs through
translations. First measure as long as #24402 is out of scope.
(cherry picked from commit 83f37f630246e381eefd650fc2d4b1f3976ea882)
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Conflicts:
- options/locale/locale_en-US.ini
Resolved by manually applying the URL->%s changes to our translations.
- routers/web/admin/hooks.go
templates/repo/settings/protected_branch.tmpl
templates/status/500.tmpl
Manually resolved.
- templates/repo/settings/webhook/settings.tmpl
Applied the change to templates/webhook/shared-settings.tmpl
instead
Additional changes: Gitea-specific URLs have been replaced by their
Forgejo counterparts, lifted from the original translation text.
- when the PR title has the maximum length, the WIP toggle switch does nothing
- work around this by slightly reducing the max input size (- 10 characters for eventually long prefixes)
- test WIP toggling edge case in playwright
fix(e2e): increase timeouts
A look at recent runs suggests they should be increased globally. The timeouts in the config file have no timeout by default.
- Follow up of #4819
- When no `ssh` executable is present, disable the UI and backend bits
that allow the creation of push mirrors that use SSH authentication. As
this feature requires the usage of the `ssh` binary.
- Integration test added.
This Pull Request adds missing tool tips for the protected, copy, and rss icons on the branch list page. It also moved protected icon position after the branch name.
(cherry picked from commit 40036b610224338ff730acb6e182aa8a6ebdb009)
- adds a header to indicate creating a new rule
- test that header is different between new and edit form
- consistently avoids colons in the form
- excludes some accessibility checks that require a global solution for
forms
- Continuation of https://github.com/go-gitea/gitea/pull/18835 (by
@Gusted, so it's fine to change copyright holder to Forgejo).
- Add the option to use SSH for push mirrors, this would allow for the
deploy keys feature to be used and not require tokens to be used which
cannot be limited to a specific repository. The private key is stored
encrypted (via the `keying` module) on the database and NEVER given to
the user, to avoid accidental exposure and misuse.
- CAVEAT: This does require the `ssh` binary to be present, which may
not be available in containerized environments, this could be solved by
adding a SSH client into forgejo itself and use the forgejo binary as
SSH command, but should be done in another PR.
- CAVEAT: Mirroring of LFS content is not supported, this would require
the previous stated problem to be solved due to LFS authentication (an
attempt was made at forgejo/forgejo#2544).
- Integration test added.
- Resolves#4416
Modifies forms:
- (new) org team
- (new) repo webhook
- (new) repo protected branch
The forms are not completely rewritten to semantic HTML yet. The focus
of this change was on standard elements, some custom solutions were left
untouched for now.
- swaps the order fo permission radio buttons as per https://codeberg.org/forgejo/forgejo/issues/4983
- uses fieldsets to group related inputs
- ensures consistent styling across forms
- can be improved later, e.g. using horizontal lines between sections
- fixes: previous font size of labels was smaller than the font size of the help text
- help text are now part of the label, clicking them now also activates the input
- drop unused CSS (no required checkboxes in grouped class remain)
- playwright testing:
- move login boilerplate to utils
- automated form accessibility checking
- allow defining the scope, because legacy parts of the forms are not yet accessible
- assert some CSS properties that should not be overriden
- the Makefile adjustment was necessary, because eslint scanned some internal files in the tests/e2e/reports directory
The forgejo/forgejo#2367 pull requests added rel="nofollow" on filters in the
menu, this commit adds it on the labels in the listing and a few other places.
This reverts commit 4ed372af13.
This change from Gitea was not considered by the Forgejo UI team and there is a consensus that it feels like a regression.
The test which was added in that commit is kept and modified to test that reviews can successfully be submitted on closed and merged PRs.
Closesforgejo/design#11
---
Conflict resolution: trivial
Things done differently: Improve localization message, use the paragraph
element instead of the div element, fix passing this variable to the
template and add a integration test
(cherry picked from commit 9633f336c87947dc7d2a5e76077a10699ba5e50d)
`BranchName` provides the nearest branch of the requested `:commit`.
It's plenty fast on smaller repositories.
On larger repositories like nixpkgs, however, this can easily take 2-3
seconds on a modern machine on a NVMe.
For context, at the time of writing, nixpkgs has over 650k commits and
roughly 250 branches.
`BranchName` is used once in the whole view:
The cherry-pick target branch default selection.
And I believe that's a logic error, which is why this patch is so small.
The nearest branch of a given commit will always be a branch the commit
is already part of. The branch you most likely *don't* want to
cherry-pick to.
Sure, one can technically cherry-pick a commit onto the same branch, but
that simply results in an empty commit.
I don't believe this is intended and even less so worth the compute.
Instead, the cherry-pick branch selection suggestion now always uses
the default branch, which used to be the fallback.
If a user wants to know which branches contain the given commit,
`load-branches-and-tags` exists and should be used instead.
Also, to add insult to injury, `BranchName` was calculated for both
logged-in and not logged-in users, despite its only consumer, the
cherry-pick operation, only being rendered when a given user has
write/commit permissions.
But this isn't particularly surprising, given this happens a lot in
Forgejo's codebase.
- Adjust the counting of the number of lines of a file to match the
amount of rendered lines. This simply means that a file with the content
of `a\n` will be shown as having `1 line` rather than `2 lines`. This
matches with the amount of lines that are being rendered (the last empty
line is never rendered) and matches more with the expecation of the
user (a trailing EOL is a technical detail).
- In the case there's no EOL, the reason why it was counting
'incorrectly' was to show if there was a trailing EOL or not, but now
text is shown to tell the user this.
- Integration test added.
- ResolvesCodeberg/Community#1612
