This fixes `initRepoPullRequestAllowMaintainerEdit()` to submit the form correctly (as a web form, rather than as JSON payload).
Fixes#3618, cherry picked from gitea#30854.
Co-Authored-By: wxiaoguang <wxiaoguang@gmail.com>
---
Manual testing steps:
- Open a PR against any repository, with the "Allow edits from maintainers" option checked.
- Open the developer console (`Ctrl-Shift-I` on Firefox), and look at the Network tab.
- Visit the PR, find the "Allow edits from maintainers" checkbox, and click it.
- See the developer console, and check that the response says the setting is false.
- Refresh the page *completely* (`Ctrl-Shift-R` on Firefox)
- Observe that the setting is off.
- Click the box again to enable it.
- See the developer console, and check that the response says the setting is true.
- Reload without cache again (`Ctrl-Shift-R` on Firefox)
- Observe that the setting is now on.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3675
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Co-committed-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Make a pass to have a full inventory of JavaScript dependencies that
can be automerged because they only have an impact on the CI. It is
easier than to examine them one by one when an update is proposed.
- add packages:test which indirectly includes packages:jsUnitTest and
a number of test dependencies such as vitest
- add prefixes for dependencies which are known to be exclusively
used for testing (playwright, ...)
- add modules
Refs: https://docs.renovatebot.com/presets-packages
there are no tests but since Gitea uses @v1 since last month and Gitea
maintainers rely on make watch, it is safe to assume that upgrading is
not broken. Switching to v1 would require less scrutiny on the
upgrades. Even if there is breakage, it can be fixed with minimal
impact on the developer workflow.
- add a new button to the org view that is only shown to the org members
- add integration test to verify the expected navigatability
- add a new translation string to that button
- fix display style of "View <orgname>" button on the dashboard
- fix gap size between buttons on the org view by utilizing the common class top-right-buttons
We should be listing all repositories by default.
Fixes#28483.
(cherry picked from commit 9f0ef3621a3b63ccbe93f302a446b67dc54ad725)
Conflict:
- if ctx.IsSigned && ctx.Doer.IsAdmin || permission.UnitAccessMode(unit_model.TypeCode) >= perm.AccessModeRead {
+ if ctx.IsSigned && ctx.Doer.IsAdmin || permission.HasAccess() {
because of https://codeberg.org/forgejo/forgejo/pulls/2001
Fix#30807
reuse functions in services
(cherry picked from commit a50026e2f30897904704895362da0fb12c7e5b26)
Conflicts:
models/issues/issue_update.go
routers/api/v1/repo/issue.go
trivial context conflict because of 'allow setting the update date on issues and comments'
Just merge actions.go file to action.go
Signed-off-by: Bo-Yi Wu <appleboy.tw@gmail.com>
(cherry picked from commit e67fbe4f15cdc544f6bec975de6560556724f098)
This commit forces the resource owner (user) to always approve OAuth 2.0
authorization requests if the client is public (e.g. native
applications).
As detailed in [RFC 6749 Section 10.2](https://www.rfc-editor.org/rfc/rfc6749.html#section-10.2),
> The authorization server SHOULD NOT process repeated authorization
requests automatically (without active resource owner interaction)
without authenticating the client or relying on other measures to ensure
that the repeated request comes from the original client and not an
impersonator.
With the implementation prior to this patch, attackers with access to
the redirect URI (e.g., the loopback interface for
`git-credential-oauth`) can get access to the user account without any
user interaction if they can redirect the user to the
`/login/oauth/authorize` endpoint somehow (e.g., with `xdg-open` on
Linux).
Fixes#25061.
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit 5c542ca94caa3587329167cfe9e949357ca15cf1)
Before, we would just throw 500 if a user passes an attachment that is
not an allowed type. This commit catches this error and throws a 422
instead since this should be considered a validation error.
(cherry picked from commit 872caa17c0a30d95f85ab75c068d606e07bd10b3)
Conflicts:
tests/integration/api_comment_attachment_test.go
tests/integration/api_issue_attachment_test.go
trivial context conflict because of 'allow setting the update date on issues and comments'
Makes it easier to use because you see which square is currently
hovered:
<img width="314" alt="Screenshot 2024-05-02 at 15 38 20"
src="https://github.com/go-gitea/gitea/assets/115237/3a15dad1-2259-4f28-9fae-5cf6ad3d8798">
I did try a `scoped` style for this, but that did not work for some
reason.
(cherry picked from commit 6f89d5e3a0886d02ead732005f593ae003f78f78)
