Refs: https://codeberg.org/forgejo/forgejo/issues/8
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/153
Refs: https://codeberg.org/forgejo/forgejo/issues/123
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/299
(cherry picked from commit 08dcef0c8c)
[DOCS] CONTRIBUTING/RELEASE: https://forgejo.org/docs/admin
Because the version is not displayed on the landing page of Forgejo,
there cannot be a link to a versionned documentation. There must exist
a link that points to the latest version on the website for the
forgejo instance to display.
Better but more complicated approaches could be to:
* Embed the documentation in Forgejo
* Allow the admin to not display the help
* Allow the admin to display a versionned help or not
(cherry picked from commit 83cc389239)
(cherry picked from commit 5df52b8a4f)
(cherry picked from commit 9a66b3d70b)
[DOCS] CONTRIBUTING/RELEASE: reminder to update FORGEJO_VERSION
(cherry picked from commit 2a4d0bd164)
(cherry picked from commit d68576ba67)
[DOCS] CONTRIBUTING: updates
* Remove obsolete description of the well being & moderation team and
replace them with a link to the moderation email.
* Remove description of the governance process and replace with a link
to the governance readme that did not exist at the time.
* Add links to the Forgejo documentation
(cherry picked from commit df749da272)
(cherry picked from commit 4da39128c5)
Although it would be possible to modify these files, it would create
conflicts when rebasing. Instead, this commit removes them entirely
and another commit can start from scratch, borrowing content from the
original files.
The drawback of this approach is that some content updates from Gitea
that also need updating in Forgejo will have to be copy/pasted
instead of being merged.
(cherry picked from commit eb85782115)
(cherry picked from commit 34401f2004)
(cherry picked from commit ef43b1c691)
(cherry picked from commit d17fe25e2f)
(cherry picked from commit 3f65dea3e7)
(cherry picked from commit 3cacb64a1b)
(cherry picked from commit b531b014b7)
f92e0a4018 added minio to the tests/pgsql.ini.tmpl and Forgejo CI does
not run a minio server. It will if there are external storage related
changes at some point but it is not the case now so it is not worth
the burden.
(cherry picked from commit 4cfbf4718d)
(cherry picked from commit 9bd644d601)
(cherry picked from commit 604636c7c4)
I neglected that the `NameKey` of `Unit` is not only for translation,
but also configuration. So it should be `repo.actions` to maintain
consistency.
## ⚠️ BREAKING ⚠️
If users already use `actions.actions` in `DISABLED_REPO_UNITS` or
`DEFAULT_REPO_UNITS`, it will be treated as an invalid unit key.
Externalize clipboard copying to the
[clippie](https://github.com/silverwind/clippie) module which I feel I
can maintain outside this repo for shared benefit with my other
projects.
The module is feature-equivalent to the previous code and has one
improvement where it sets `aria-hidden` on the fallback textarea,
preventing screen readers from picking it up. Also it support `Array` of
`content` as well to copy multiple items at once, in case it's ever
needed.
When doing the refactoring:
* #22950
I added some debug mode code (assertShown) to help to catch bugs, it did
catch some bugs like:
* #23074
If it has been proved that there is no more bugs, this assertion could
be removed easily and clearly.
Feel free to decide when to remove it (feel free to convert it from
Draft to Ready for Review).
cc: @silverwind
Caught by @justusbunsi
An old bug from #6488
In `pullrequest_targetbranch_change`, the `data` might be empty, because
`UpdatePullRequestTarget` may respond `http.StatusNoContent`.
And the old code's `$branchTarget.text(data.base_branch);` doesn't make
sense, because in the end, the page will be always reloaded.
So, just remove the `$branchTarget.text(data.base_branch);`, everything
should be fine.
Close#23680
Some CLI programs use "\r" and control chars to print new content in
current line.
So, the strings in one line are actually from
`\rReading...1%\rReading...5%\rReading...100%`
This PR tries to make the output better.
Follow #23633 and #23240Close#23814
Now we almost have a complete test set for Gitea's LocalStore.
This PR is still a quick fix for the legacy locale system (see the
TODOs), to resolve the problems fundamentally, it needs more work in the
future.
Changes:
- `RenderWithErr` should render `tplUserEdit` not `tplUserNew` in edit
page
- If error occurred in `HandleUsernameChange` redirect to original edit
page instead of user list page
ps: there are more broken translation strings in 1.20 (main), most of
them are still caused by incorrect quoting/unquoting. For example,
translators might write text ``` `my text ```, such incorrect encoding
might break crowdin & Gitea's locale package.
In the future, a Go `update-locales.go` should replace the legacy
`update-locales.sh`.
Follow #21962
After I eat my own dogfood, I would say that
ONLY_SHOW_RELEVANT_REPOS=false is necessary for many private/enterprise
instances, because many private repositories do not have
"description/topic", users just want to search by their names.
This PR also adds `PageIsExploreRepositories` check, to make code more
strict, because the `search` template is shared for different purpose.
And during the test, I found a bug that the "Search" button didn't
respect the "relevant" parameter, so this PR fixes the bug by the way
together.
I think this PR needs to be backported.
When running listLdapGroupMemberships check if the groupFilter is empty
before using it to list memberships.
Fix#23615
Signed-off-by: Andrew Thornton <art27@cantab.net>
# Why this PR comes
At first, I'd like to help users like #23636 (there are a lot)
The unclear "Internal Server Error" is quite anonying, scare users,
frustrate contributors, nobody knows what happens.
So, it's always good to provide meaningful messages to end users (of
course, do not leak sensitive information).
When I started working on the "response message to end users", I found
that the related code has a lot of technical debt. A lot of copy&paste
code, unclear fields and usages.
So I think it's good to make everything clear.
# Tech Backgrounds
Gitea has many sub-commands, some are used by admins, some are used by
SSH servers or Git Hooks. Many sub-commands use "internal API" to
communicate with Gitea web server.
Before, Gitea server always use `StatusCode + Json "err" field` to
return messages.
* The CLI sub-commands: they expect to show all error related messages
to site admin
* The Serv/Hook sub-commands (for git clients): they could only show
safe messages to end users, the error log could only be recorded by
"SSHLog" to Gitea web server.
In the old design, it assumes that:
* If the StatusCode is 500 (in some functions), then the "err" field is
error log, shouldn't be exposed to git client.
* If the StatusCode is 40x, then the "err" field could be exposed. And
some functions always read the "err" no matter what the StatusCode is.
The old code is not strict, and it's difficult to distinguish the
messages clearly and then output them correctly.
# This PR
To help to remove duplicate code and make everything clear, this PR
introduces `ResponseExtra` and `requestJSONResp`.
* `ResponseExtra` is a struct which contains "extra" information of a
internal API response, including StatusCode, UserMsg, Error
* `requestJSONResp` is a generic function which can be used for all
cases to help to simplify the calls.
* Remove all `map["err"]`, always use `private.Response{Err}` to
construct error messages.
* User messages and error messages are separated clearly, the `fail` and
`handleCliResponseExtra` will output correct messages.
* Replace all `Internal Server Error` messages with meaningful (still
safe) messages.
This PR saves more than 300 lines, while makes the git client messages
more clear.
Many gitea-serv/git-hook related essential functions are covered by
tests.
---------
Co-authored-by: delvh <dev.lh@web.de>
