fix pagination for followers and following (#27127) (#27138)
Backport #27127 by @earl-warren
- Use the correct total amount for pagination. Thereby correctly show
the pagination bare when there's more than one page of
followers/followings.
Refs: https://codeberg.org/forgejo/forgejo/pulls/1477
(cherry picked from commit c1a136318b)
Co-authored-by: Earl Warren <109468362+earl-warren@users.noreply.github.com>
Co-authored-by: Gusted <postmaster@gusted.xyz>
manual backport of #25988 to v1.20
- Tell the renderer to use the `document` mode, so it's consistent with
other renderers.
- Use the same padding as `.file-view.markup`, so it's consistent with
other containers that contain markup rendering.
- Resolves https://codeberg.org/forgejo/forgejo/issues/833
Co-authored-by: Earl Warren <109468362+earl-warren@users.noreply.github.com>
Add transaction when creating pull request created dirty data (#26259) (#26437)
Backport #26259
This PR will introduce a transaction on creating pull request so that if
some step failed, it will rollback totally. And there will be no dirty
pull request exist.
Co-authored-by: Giteabot <teabot@gitea.io>
Introduce ctx.PathParamRaw to avoid incorrect unescaping (#26392) (#26405)
Backport #26392 by @wxiaoguang
Fix #26389
And complete an old TODO: `ctx.Params does un-escaping,..., which is
incorrect.`
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Fix pull request check list is limited (#26179) (#26245)
Backport #26179 by @CaiCandong
In the original implementation, we can only get the first 30 records of
the commit status (the default paging size), if the commit status is
more than 30, it will lead to the bug #25990. I made the following two
changes.
- On the page, use the ` db.ListOptions{ListAll: true}` parameter
instead of `db.ListOptions{}`
- The `GetLatestCommitStatus` function makes a determination as to
whether or not a pager is being used.
fixed #25990
Co-authored-by: caicandong <50507092+CaiCandong@users.noreply.github.com>
Fix access check for org-level project (#26182) (#26223)
Backport #26182 by @Zettat123
Fix #25934
Add `ignoreGlobal` parameter to `reqUnitAccess` and only check global
disabled units when `ignoreGlobal` is true. So the org-level projects
and user-level projects won't be affected by global disabled
`repo.projects` unit.
Co-authored-by: Zettat123 <zettat123@gmail.com>
Fix the route for pull-request's authors (#26016) (#26018)
Backport #26016 by @wxiaoguang
Close #25906
Succeeded logs:
```
[I] router: completed GET /root/test/issues/posters?&q=%20&_=1689853025011 for [::1]:59271, 200 OK in 127.7ms @ repo/issue.go:3505(repo.IssuePosters)
[I] router: completed GET /root/test/pulls/posters?&q=%20&_=1689853968204 for [::1]:59269, 200 OK in 94.3ms @ repo/issue.go:3509(repo.PullPosters)
```
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Fix incorrect oldest sort in project list (#25806) (#25835)
Backport #25806 by @yp05327
sort type `oldest` should be `Asc`.
Added a test for this.
I see we have `SearchOrderBy` in db model, but we are using many
different ways to define the sort type.
~Maybe we can improve this later.~
↑ Improved in this PR
Co-authored-by: yp05327 <576951401@qq.com>
Backport #25781 by @wxiaoguang
Fix #25627
1. `ctx.Data["Link"]` should use relative URL but not AppURL
2. The `data-params` is incorrect because it doesn't contain "page". JS
can simply use "window.location.search" to construct the AJAX URL
3. The `data-xxx` and `id` in notification_subscriptions.tmpl were
copied&pasted, they don't have affect.
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Make "cancel" buttons have proper type in modal forms (#25618) (#25641)
Replace #25446, fix #25438
All "cancel" buttons which do not have "type" should not submit the
form, should not be triggered by "Enter".
This is a complete fix for all modal dialogs.
The major change is "modules/aria/modal.js", "devtest" related code is
for demo/test purpose.
Redirect to package after version deletion (#25594) (#25599)
Related #25559
Current behaviour:
1. Deletion of a package version
2. Redirect to the owners package list
New behaviour:
1. Deletion of a package version
2.1. If there are more versions available, redirect to the package again
2.2. If there are no versions available, redirect to the owners package
list
Backport #25330
# The problem
There were many "path tricks":
* By default, Gitea uses its program directory as its work path
* Gitea tries to use the "work path" to guess its "custom path" and
"custom conf (app.ini)"
* Users might want to use other directories as work path
* The non-default work path should be passed to Gitea by GITEA_WORK_DIR
or "--work-path"
* But some Gitea processes are started without these values
* The "serv" process started by OpenSSH server
* The CLI sub-commands started by site admin
* The paths are guessed by SetCustomPathAndConf again and again
* The default values of "work path / custom path / custom conf" can be
changed when compiling
# The solution
* Use `InitWorkPathAndCommonConfig` to handle these path tricks, and use
test code to cover its behaviors.
* When Gitea's web server runs, write the WORK_PATH to "app.ini", this
value must be the most correct one, because if this value is not right,
users would find that the web UI doesn't work and then they should be
able to fix it.
* Then all other sub-commands can use the WORK_PATH in app.ini to
initialize their paths.
* By the way, when Gitea starts for git protocol, it shouldn't output
any log, otherwise the git protocol gets broken and client blocks
forever.
The "work path" priority is: WORK_PATH in app.ini > cmd arg --work-path
> env var GITEA_WORK_DIR > builtin default
The "app.ini" searching order is: cmd arg --config > cmd arg "work path
/ custom path" > env var "work path / custom path" > builtin default
## ⚠️ BREAKING
If your instance's "work path / custom path / custom conf" doesn't meet
the requirements (eg: work path must be absolute), Gitea will report a
fatal error and exit. You need to set these values according to the
error log.
Fix all possible setting error related storages and added some tests (#23911) (#25244)
Backport #23911 by @lunny
Follow up #22405
Fix #20703
This PR rewrites storage configuration read sequences with some breaks
and tests. It becomes more strict than before and also fixed some
inherit problems.
- Move storage's MinioConfig struct into setting, so after the
configuration loading, the values will be stored into the struct but not
still on some section.
- All storages configurations should be stored on one section,
configuration items cannot be overrided by multiple sections. The
prioioty of configuration is `[attachment]` > `[storage.attachments]` |
`[storage.customized]` > `[storage]` > `default`
- For extra override configuration items, currently are `SERVE_DIRECT`,
`MINIO_BASE_PATH`, `MINIO_BUCKET`, which could be configured in another
section. The prioioty of the override configuration is `[attachment]` >
`[storage.attachments]` > `default`.
- Add more tests for storages configurations.
- Update the storage documentations.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Giteabot
yp05327
Lunny Xiao
a1012112796
crystal
wxiaoguang
silverwind
KN4CK3R
sebastian-sauer