Fixes#28853
Needs both https://gitea.com/gitea/act_runner/pulls/473 and
https://gitea.com/gitea/act_runner/pulls/471 on the runner side and
patched `actions/upload-artifact@v4` / `actions/download-artifact@v4`,
like `christopherhx/gitea-upload-artifact@v4` and
`christopherhx/gitea-download-artifact@v4`, to not return errors due to
GHES not beeing supported yet.
(cherry picked from commit a53d268aca87a281aadc2246541f8749eddcebed)
Str2html was abused a lot. So use a proper name for it: SanitizeHTML
And add some tests to show its behavior.
(cherry picked from commit fb42972c057364a1dc99dfb528554e7a94415be7)
Conflicts:
docs/content/administration/mail-templates.en-us.md
docs/content/administration/mail-templates.zh-cn.md
prefer their version always
This PR touches the most interesting part of the "template refactoring".
1. Unclear variable type. Especially for "web/feed/convert.go":
sometimes it uses text, sometimes it uses HTML.
2. Assign text content to "RenderedContent" field, for example: `
project.RenderedContent = project.Description` in web/org/projects.go
3. Assign rendered content to text field, for example: `r.Note =
rendered content` in web/repo/release.go
4. (possible) Incorrectly calling `{{Str2html
.PackageDescriptor.Metadata.ReleaseNotes}}` in
package/content/nuget.tmpl, I guess the name Str2html misleads
developers to use it to "render string to html", but it only sanitizes.
if ReleaseNotes really contains HTML, then this is not a problem.
(cherry picked from commit e71eb8930a5d0f60874b038c223498b41ad65592)
Conflicts:
modules/templates/util_string.go
trivial context conflict
just some refactoring bits towards replacing **util.OptionalBool** with
**optional.Option[bool]**
---------
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
(cherry picked from commit f6656181e4a07d6c415927220efa2077d509f7c6)
Conflicts:
models/repo/repo_list_test.go
trivial shared fixture count conflicts
just some refactoring bits towards replacing **util.OptionalBool** with
**optional.Option[bool]**
(cherry picked from commit 274c0aea2e88db9bc41690c90e13e8aedf6193d4)
Thanks to inferenceus : some sort orders on the "explore/users" page
could list users by their lastlogintime/updatetime.
It leaks user's activity unintentionally. This PR makes that page only
use "supported" sort orders.
Removing the "sort orders" could also be a good solution, while IMO at
the moment keeping the "create time" and "name" orders is also fine, in
case some users would like to find a target user in the search result,
the "sort order" might help.
![image](https://github.com/go-gitea/gitea/assets/2114189/ce5c39c1-1e86-484a-80c3-33cac6419af8)
(cherry picked from commit eedb8f41297c343d6073a7bab46e4df6ee297a90)
Previously, it will be treated as "re-run all jobs" when `jobIndex ==
0`. So when you click re-run button on the first job, it triggers all
the jobs actually.
(cherry picked from commit bad4ad70181c747599e206c0e7a87b57c997385d)
Since `modules/context` has to depend on `models` and many other
packages, it should be moved from `modules/context` to
`services/context` according to design principles. There is no logic
code change on this PR, only move packages.
- Move `code.gitea.io/gitea/modules/context` to
`code.gitea.io/gitea/services/context`
- Move `code.gitea.io/gitea/modules/contexttest` to
`code.gitea.io/gitea/services/contexttest` because of depending on
context
- Move `code.gitea.io/gitea/modules/upload` to
`code.gitea.io/gitea/services/context/upload` because of depending on
context
(cherry picked from commit 29f149bd9f517225a3c9f1ca3fb0a7b5325af696)
Conflicts:
routers/api/packages/alpine/alpine.go
routers/api/v1/repo/issue_reaction.go
routers/install/install.go
routers/web/admin/config.go
routers/web/passkey.go
routers/web/repo/search.go
routers/web/repo/setting/default_branch.go
routers/web/user/home.go
routers/web/user/profile.go
tests/integration/editor_test.go
tests/integration/integration_test.go
tests/integration/mirror_push_test.go
trivial context conflicts
also modified all other occurrences in Forgejo specific files
- When a user goes opens a symlink file in Forgejo, the file would be
rendered with the path of the symlink as content.
- Add a button that is shown when the user opens a *valid* symlink file,
which means that the symlink must have an valid path to an existent
file and after 999 follows isn't a symlink anymore.
- Return the relative path from the `FollowLink` functions, because Git
really doesn't want to tell where an file is located based on the blob ID.
- Adds integration tests.
- Implement the commit mail selection feature for the other supported
Git operations that can be done trough the web UI.
- Adds integration tests (goodluck reviewing this).
- Ref: #1788
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
The `repo.SingleRelease` handler was broken by gitea#29149, as the
switch to `getReleaseInfos` stopped returning tags without an associated
release. This resulted in the web UI showing a 404 when trying to view a
tag without a release.
This restores the functionality by explicitly including tags in the
search, and also adds tests to exercise the fix.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
RenderEmojiPlain(emoji.ReplaceAliases) should be called explicitly for
some contents, but not for everything.
Actually in modern days, in most cases it doesn't need such
"ReplaceAliases". So only keep it for issue/PR titles.
If anyone really needs to do ReplaceAliases for some contents, I will
propose a following fix.
(cherry picked from commit 10c7996b5a5c705964fc6cc9c1817eea1fc436ef)
Conflicts:
templates/base/head.tmpl
context
Fix#14459
The following users can add/remove review requests of a PR
- the poster of the PR
- the owner or collaborators of the repository
- members with read permission on the pull requests unit
(cherry picked from commit c42083a33950be6ee9f822c6d0de3c3a79d1f51b)
Conflicts:
models/repo/repo_list_test.go
tests/integration/api_nodeinfo_test.go
tests/integration/api_repo_test.go
shared fixture counts
This is the implementation of Recent Commits page. This feature was
mentioned on #18262.
It adds another tab to Activity page called Recent Commits. Recent
Commits tab shows number of commits since last year for the repository.
(cherry picked from commit d3982bcd814bac93e3cbce1c7eb749b17e413fbd)
Now we can get object format name from git command line or from the
database repository table. Assume the column is right, we don't need to
read from git command line every time.
This also fixed a possible bug that the object format is wrong when
migrating a sha256 repository from external.
<img width="658" alt="image"
src="https://github.com/go-gitea/gitea/assets/81045/6e9a9dcf-13bf-4267-928b-6bf2c2560423">
(cherry picked from commit b79c30435f439af8243ee281310258cdf141e27b)
Conflicts:
routers/web/repo/blame.go
services/agit/agit.go
context
### Overview
This is the implementation of Code Frequency page. This feature was
mentioned on these issues: #18262, #7392.
It adds another tab to Activity page called Code Frequency. Code
Frequency tab shows additions and deletions over time since the
repository existed.
Before:
<img width="1296" alt="image"
src="https://github.com/go-gitea/gitea/assets/32161460/2603504f-aee7-4929-a8c4-fb3412a7a0f6">
After:
<img width="1296" alt="image"
src="https://github.com/go-gitea/gitea/assets/32161460/58c03721-729f-4536-a663-9f337f240963">
---
#### Features
- See additions deletions over time since repository existed
- Click on "Additions" or "Deletions" legend to show only one type of
contribution
- Use the same cache from Contributors page so that the loading of data
will be fast once it is cached by visiting either one of the pages
---------
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 875f5ea6d83c8371f309df99654ca3556623004c)
Extract from #20549
This PR added a new option on app.ini `[admin]USER_DISABLED_FEATURES` to
allow the site administrator to disable users visiting deletion user
interface or allow.
This options are also potentially allowed to define more features in
future PRs.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit 3ef6252e06a1f3981f8b7d1717bfc581418b1dc5)
Conflicts:
custom/conf/app.example.ini
docs/content/administration/config-cheat-sheet.en-us.md
modules/setting/admin.go
context
Similarly to how `[repository].DISABLE_FORKS` works, lets make
`[repository].DISABLE_STARS` disable the routes too, not just hide the
functionality from the UI.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Split up `repo.Action` in `routers/web` into smaller functions.
While some of the functionality was very similar (starring / watching),
they are ultimately separate actions. Rather than collecting all of them
under a single handler (`repo.Action`), split them up into smaller,
independent functions.
This does result in a little bit of code duplication, but the
independent functions should be easier to follow and understand.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
The "desc" action has not been used since at least 2016, probably much
earlier. It's an ancient Gogs artifact - drop it.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
- If a user tries to create another protected branching rule that
specifies a set of branches already used by another rule, do not allow
it.
- Update the translation accordingly.
- Adds integration test.
- Resolves#2455
For small, personal self-hosted instances with no user signups, the fork
button is just a noise. This patch allows disabling them like stars can
be disabled too.
Disabling forks does not only remove the buttons from the web UI, it
also disables the routes that could be used to create forks.
Fixes#2441.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
As suggested by @Gusted in #2431, move the permission checking from
`ArtifactsDeleteView` into the route instead, where it belongs.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Adds a label to Pull Requests that were created using AGit-Flow,
in order to prevent situations where a contributor uses AGit-Flow
to push new changes - only to realize that they did not use AGit-Flow
in the first place, and that they just opened a new PR accidentally
(that was me).
Also intended to raise general awareness about the feature. Some
additional work, such as adding a tooltip, still needs to be
done.
A small typo fix for a comment and (exclusively) formatting fixes
in the copyright header are also included.
Refs: https://codeberg.org/forgejo/forgejo/issues/2433
- The ambiguous character detection is an important security feature to
combat against sourcebase attacks (https://trojansource.codes/).
- However there are a few problems with the feature as it stands
today (i) it's apparantly an big performance hitter, it's twice as slow
as syntax highlighting (ii) it contains false positives, because it's
reporting valid problems but not valid within the context of a
programming language (ambiguous charachters in code comments being a
prime example) that can lead to security issues (iii) charachters from
certain languages always being marked as ambiguous. It's a lot of effort
to fix the aforementioned issues.
- Therefore, make it configurable in which context the ambiguous
character detection should be run, this avoids running detection in all
contexts such as file views, but still enable it in commits and pull
requests diffs where it matters the most. Ideally this also becomes an
per-repository setting, but the code architecture doesn't allow for a
clean implementation of that.
- Adds unit test.
- Adds integration tests to ensure that the contexts and instance-wide
is respected (and that ambigious charachter detection actually work in
different places).
- Ref: https://codeberg.org/forgejo/forgejo/pulls/2395#issuecomment-1575547
- Ref: https://codeberg.org/forgejo/forgejo/issues/564
- Instead of relying on JSON to convert the struct to map, use
`reflect` to do this conversion. Also simplify it a bit by only passing
one variable to the template.
- This avoids issues where the conversion to JSON causes changes in
the value, for example huge numbers are converted to its scientific
notation but are consequently not converted back when being displayed.
- Adds unit tests.
- Resolves an issue where the amount of comments is being displayed in
scientific notation on Codeberg.
Follow #29165.
* Introduce JSONTemplate to help to render JSON templates
* Introduce JSEscapeSafe for templates. Now only use `{{ ... |
JSEscape}}` instead of `{{ ... | JSEscape | Safe}}`
* Simplify "UserLocationMapURL" useage
(cherry picked from commit 31bb9f3247388b993c61a10190cfd512408ce57e)
- Currently there exists a restriction to not render and show files that
are larger than what's configured in `[UI].MAX_DISPLAY_FILE_SIZE`.
- Apply the same restriction to the blame operation as well, as the
blame operation can be seen as displaying a file.
- Add integration test.
- Ref: #2394
- following organization is broken from #28908
- add login check for the follow button in organization profile page
(cherry picked from commit 68227996a7a84a240b36c304d04c5c8d82948df8)
- Refactor the system status list into its own template
- Change the backend to return only the system status if htmx initiated
the request
- `hx-get="{{$.Link}}/system_status`: reuse the backend handler
- `hx-swap="innerHTML"`: replace the `<div>`'s innerHTML (essentially
the new template)
- `hx-trigger="every 5s"`: call every 5 seconds
- `hx-indicator=".divider"`: the `is-loading` class shouldn't be added
to the div during the request, so set it on an element it has no effect
on
- Render "Since Last GC Time" with `<relative-time>`, so we send a
timestamp
# Auto-update in action GIF
![action](https://github.com/go-gitea/gitea/assets/20454870/c6e1f220-f0fb-4460-ac3b-59f315e30e29)
---------
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
Co-authored-by: silverwind <me@silverwind.io>
(cherry picked from commit c70f65e83bc1876fb368fd117d342573ff18a9e8)
Continuation of https://github.com/go-gitea/gitea/pull/25439. Fixes#847
Before:
<img width="1296" alt="image"
src="https://github.com/go-gitea/gitea/assets/32161460/24571ac8-b254-43c9-b178-97340f0dc8a9">
----
After:
<img width="1296" alt="image"
src="https://github.com/go-gitea/gitea/assets/32161460/c60b2459-9d10-4d42-8d83-d5ef0f45bf94">
---
#### Overview
This is the implementation of a requested feature: Contributors graph
(#847)
It makes Activity page a multi-tab page and adds a new tab called
Contributors. Contributors tab shows the contribution graphs over time
since the repository existed. It also shows per user contribution graphs
for top 100 contributors. Top 100 is calculated based on the selected
contribution type (commits, additions or deletions).
---
#### Demo
(The demo is a bit old but still a good example to show off the main
features)
<video src="https://github.com/go-gitea/gitea/assets/32161460/9f68103f-8145-4cc2-94bc-5546daae7014" controls width="320" height="240">
<a href="https://github.com/go-gitea/gitea/assets/32161460/9f68103f-8145-4cc2-94bc-5546daae7014">Download</a>
</video>
#### Features:
- Select contribution type (commits, additions or deletions)
- See overall and per user contribution graphs for the selected
contribution type
- Zoom and pan on graphs to see them in detail
- See top 100 contributors based on the selected contribution type and
selected time range
- Go directly to users' profile by clicking their name if they are
registered gitea users
- Cache the results so that when the same repository is visited again
fetching data will be faster
---------
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: hiifong <i@hiif.ong>
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: yp05327 <576951401@qq.com>
(cherry picked from commit 21331be30cb8f6c2d8b9dd99f1061623900632b9)
- Move the conditions code around, such that the existence of the head
and base is first checked (so a clear error can be given, instead of a
possible server error). This makes it easier to read this code. As the
logic is now grouped together.
- Adds integration testing that simulates the deletion of the base and
head branch and ensures the pull request cannot be opened. The 'normal'
testcase also 'informally' ensures that the previous incorrect condition
is not there, because the branch `base-branch` doesn't exist on the head
repository.
- Resolves#2321
Clarify when "string" should be used (and be escaped), and when
"template.HTML" should be used (no need to escape)
And help PRs like #29059 , to render the error messages correctly.
(cherry picked from commit f3eb835886031df7a562abc123c3f6011c81eca8)
Conflicts:
modules/web/middleware/binding.go
routers/web/feed/convert.go
tests/integration/branches_test.go
tests/integration/repo_branch_test.go
trivial context conflicts
Follow-up of #2282 and #2296 (which tried to address #2278)
One of the issue with the previous PR is that when a conversation on the Files tab was marked as "resolved", it would fetch all the comments for that line (even the outdated ones, which should not be shown on this page - except when explicitly activated).
To properly fix this, I have changed `FetchCodeCommentsByLine` to `FetchCodeConversation`. Its role is to fetch all comments related to a given (review, path, line) and reverted my changes in the template (which were based on a misunderstanding).
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/2306
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: oliverpool <git@olivier.pfad.fr>
Co-committed-by: oliverpool <git@olivier.pfad.fr>
With this option, it is possible to require a linear commit history with
the following benefits over the next best option `Rebase+fast-forward`:
The original commits continue existing, with the original signatures
continuing to stay valid instead of being rewritten, there is no merge
commit, and reverting commits becomes easier.
Closes#24906
Use `ctx.ServerError` instead of a separate `log.Error` + `ctx.Error`.
`ctx.ServerError` does essentially the same thing, but better.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This splits out the repository unit settings (formerly "Advanced
settings" under the repository settings page) into their own, separate
page.
The primary reason for this is that the settings page became long and
complicated, with a structure that not always made sense. A secondary
reason is that toggling units on and off should not necessarily be an
"advanced" setting. We want to make doing that easier, and having the
units on their own page helps with that.
This is basically a refactor, there is no new functionality introduced,
just an extra pair of routes for the new page, and the supporting code.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
`ctx.Error` only displays the text but `ctx.ServerError` renders the
usual error page.
(cherry picked from commit da2f03750f9672c5aac48209539874f2af2673f1)
This adds a new route at `/actions/workflows/{workflow}/runs/latest`,
which will redirect to the latest run of the given workflow. It can be
further restricted by specifying an optional `?branch={branch}` query
parameter. If no branch is specified, the route defaults to using the
repo's default branch.
This route is meant to go hand in hand with the Badge route that returns
the result of the same workflow as a badge. This route can be used to
link to the run that produced that result.
Fixes#2303.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Forking a repository via the web UI currently requires visiting a
`/repo/fork/{{repoid}}` URL. This makes it cumbersome to create a link
that starts a fork, because the repository ID is only available via the
API. While it *is* possible to create a link, doing so requires extra
steps.
To make it easier to have a "Fork me!"-style links, introduce the
`/{username}/{repo}/fork` route, which will start the forking process
based on the repository in context instead.
The old `/repo/fork/{repoid}` route (with a `GET` request) will remain
there for the sake of backwards compatibility, but will redirect to the
new URL instead. It's `POST` handler is removed.
Tests that used the old route are updated to use the new one, and new
tests are introduced to exercise the redirect.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
The "Self Check" menu essentially runs the collation check that is also
performed at startup, and displays the results. This is only a thing for
MariaDB/MySQL and MSSQL. As such, the menu item should only be available
for these database types.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 0ca118fdc3c39c0e7adf9285e074e5878a0ca1c1)
Previously, the repo wiki was hardcoded to use `master` as its branch,
this change makes it possible to use `main` (or something else, governed
by `[repository].DEFAULT_BRANCH`, a setting that already exists and
defaults to `main`).
The way it is done is that a new column is added to the `repository`
table: `wiki_branch`. The migration will make existing repositories
default to `master`, for compatibility's sake, even if they don't have a
Wiki (because it's easier to do that). Newly created repositories will
default to `[repository].DEFAULT_BRANCH` instead.
The Wiki service was updated to use the branch name stored in the
database, and fall back to the default if it is empty.
Old repositories with Wikis using the older `master` branch will have
the option to do a one-time transition to `main`, available via the
repository settings in the "Danger Zone". This option will only be
available for repositories that have the internal wiki enabled, it is
not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`.
When migrating a repository with a Wiki, Forgejo will use the same
branch name for the wiki as the source repository did. If that's not the
same as the default, the option to normalize it will be available after
the migration's done.
Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will
now include the wiki branch name in `GET` requests, and allow changing
the wiki branch via `PATCH`.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit d87c526d2a313fa45093ab49b78bb30322b33298)
- Remove unnecessary checks for `ctx.Repo.TreePath`, because it will
already early-return if it's empty.
- Simplify `performBlame` to extract the repoPath from the context.
- Don't render the topics, as they are not shown in the blame
page (there's a condition in the template for the blame page).
- Fix that `performBlame` doesn't call `NotFound`, it should instead
only return the error.
- Fix that the error handlings call `ServerError` instead of `NotFound`.
- Simplify `bypass-blame-ignore` to use `ctx.FormBool`.
- Remove `TreeLink`, `HasParentPath` and `ParentPath` as it's not used
in the blame template.
- Inline `BranchLink` and `RawFileLink` string operations.
- Move around `NumLines` to make it clear the error is handled.
- Less code, less things the code does, more readable and thus more
maintanable!
(cherry picked from commit e02baca55c0a3ed6a806f276c8e3cf2995a88967)
(cherry picked from commit 74e00620ca4de9a2aaa51f30fdf8136b581c7a21)
When displaying the recently pushed branches banner, don't display
branches that have no common history with the default branch. These
branches are usually not meant to be merged, so the banner is just noise
in this case.
Refs: https://codeberg.org/forgejo/forgejo/pulls/2196
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit e1fba517f4c28c3027feaea73561045264f1f591)
(cherry picked from commit 2d3c81d4f2676c58e026e5a06cfc8d84ad0d48fa)
(cherry picked from commit 624a61b3b8660d53fc66f8ab3a1b0bff7a9fcb6c)
With this change, the "You pushed on branch xyz" banner will be
displayed when either the viewed repository or its base repo (if the
current one's a fork) has pull requests enabled. Previously it only
displayed if the viewed repo had PRs enabled.
Furthermore, if the viewed repository is an original repository that the
viewing user has a fork of, if the forked repository has recently pushed
branches, then the banner will appear for the original repository too.
In this case, the notification will include branches from the viewing
user's fork, and branches they pushed to the base repo, too.
Refs: https://codeberg.org/forgejo/forgejo/pulls/2195
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit a29f10661d59f6c33c5cfbee723f03f981aa6b72)
(cherry picked from commit 70c5e2021d7c385b9285622f0b2d878d3807d33c)
(cherry picked from commit 48b25be67a94f739601fbfea951ade6cdfe30691)
- It's possible that `canSoftDeleteContentHistory` is called without
`ctx.Doer` being set, such as an anonymous user requesting the
`/content-history/detail` endpoint.
- Add a simple condition to always set to `canSoftDelete` to false if an
anonymous user is requesting this, this avoids a panic in the code that
assumes `ctx.Doer` is set.
- Added integration testing.
(cherry picked from commit 0b5db0dcc608e9a9e79ead094a20a7775c4f9559)
(cherry picked from commit 30d168bcc867387f3c94582a4668cce62f77c171)
(cherry picked from commit 19be82b7ef11fe6e0656434dcc69c9ff2f24c702)
(cherry picked from commit 334b703b17a3fbb02e5ad20aea7241a909eb1f13)
This implements "repository flags", a way for instance administrators to
assign custom flags to repositories. The idea is that custom templates
can look at these flags, and display banners based on them, Forgejo does
not provide anything built on top of it, just the foundation. The
feature is optional, and disabled by default. To enable it, set
`[repository].ENABLE_FLAGS = true`.
On the UI side, instance administrators will see a new "Manage flags"
tab on repositories, and a list of enabled tags (if any) on the
repository home page. The "Manage flags" page allows them to remove
existing flags, or add any new ones that are listed in
`[repository].SETTABLE_FLAGS`.
The model does not enforce that only the `SETTABLE_FLAGS` are present.
If the setting is changed, old flags may remain present in the database,
and anything that uses them, will still work. The repository flag
management page will allow an instance administrator to remove them, but
not set them, once removed.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit ba735ce2228f8dd7ca105e94b9baa1be058ebe37)
(cherry picked from commit f09f6e029b4fb2714b86cd32dc19255078ecc0ee)
(cherry picked from commit 2f8b0414892f6099f519bda63a9e0fbc8ba6cfc7)
(cherry picked from commit d3186ee5f41fac896c7d2341402fcd39dd250bf1)
When trying to find a `README.md` in a `.profile` repo, do so case
insensitively. This change does not make it possible to render readmes
in formats other than Markdown, it just removes the hard-coded
"README.md".
Also adds a few tests to make sure the change works.
Fixes#1494.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit edd219d8e9d69becb9814ab0a8359555e80fcd4f)
(cherry picked from commit 2c0105ef17b9673e6892a66aa689af7c5c87b8a1)
(cherry picked from commit 3975a9f3aaf8ed3ceb5788abc325dbe8e89225d3)
(cherry picked from commit dee4a18423151ac7f22221e6fce12d863921c200)
(cherry picked from commit 60aee6370fb15b12fffc6f29582dd4a235f87d94)
Adds a new `/{username}/{repo}/badges` family of routes, which redirect
to various shields.io badges. The goal is to not reimplement badge
generation, and delegate it to shields.io (or a similar service), which
are already used by many. This way, we get all the goodies that come
with it: different styles, colors, logos, you name it.
So these routes are just thin wrappers around shields.io that make it
easier to display the information we want. The URL is configurable via
`app.ini`, and is templatable, allowing to use alternative badge
generator services with slightly different URL patterns.
Additionally, for compatibility with GitHub, there's an
`/{username}/{repo}/actions/workflows/{workflow_file}/badge.svg` route
that works much the same way as on GitHub. Change the hostname in the
URL, and done.
Fixes gitea#5633, gitea#23688, and also fixes#126.
Work sponsored by Codeberg e.V.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit fcd0f61212d8febd4bdfc27e61a4e13cbdd16d49)
(cherry picked from commit 20d14f784490a880c51ca0f0a6a5988a01887635)
(cherry picked from commit 4359741431bb39de4cf24de8b0cfb513f5233f55)
(cherry picked from commit 35cff45eb86177e750cd22e82a201880a5efe045)
(cherry picked from commit 2fc0d0b8a302d24177a00ab48b42ce083b52e506)
When displaying the repo home view, do not redirect to unit types that
can't be defaults (which, at the moment, are the external wiki and issue
tracker unit types).
If we'd redirect to those, that would mean that a repository with the
Code unit disabled, and an external issue tracker would immediately
redirect to the external issue tracker, making it harder to reach other,
non-external units of the repo.
Fixes#1965.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 44078e546022e25f5c805ef047fbc3b7c6075ec0)
(cherry picked from commit 1868dec2e4c2ba8e6807336e6dabd83e6138bcac)
(cherry picked from commit c3a8e9887092c8c089462a1cdb22a404aa11beb6)
(cherry picked from commit 9266b1916f1577075b0bf2ff14c7412cbd7cae43)
(cherry picked from commit 8fa5ff65af91c33df692a52457fe65e71c4bc3c1)
- The endpoint was moved from being an API endpoint to an web endpoint
with JSON result. However the API context isn't the same as the web
context, for example the `ctx.Error` only takes in the first two
arguments into consideration and doesn't do logging, which is not the
same behavior as the API context where there's three arguments and does
do logging and only reveal the function + error if the user is admin.
- Remove any details in the error message and do the logging seperatly,
this is somewhat consistent with how other API endpoints behave.
- Ref: https://codeberg.org/forgejo/forgejo/issues/1998
(cherry picked from commit fe71e32ace98461398cffe55f99ad31dc1be0b4e)
(cherry picked from commit c89e0735fab6b3994ff1769afafb012d1147972f)
(cherry picked from commit 4c04dcfc59c1a23b990f9a81c73de7cbfd95d1e3)
(cherry picked from commit 66eae1041c3b6bd4f15bbbaf552678313bcae835)
(cherry picked from commit 7b70fa9392cc03121c798407363712d6e5dde536)
(cherry picked from commit abf64ca0e3fd3159890c6e418ec4eab5284f26b5)
This is largely based on gitea#6312 by @ashimokawa, with updates and
fixes by myself, and incorporates the review feedback given in that pull
request, and more.
What this patch does is add a new "default_permissions" column to the
`repo_units` table (defaulting to read permission), adjusts the
permission checking code to take this into consideration, and then
exposes a setting that lets a repo administrator enable any user on a
Forgejo instance to edit the repo's wiki (effectively giving the wiki
unit of the repo "write" permissions by default).
By default, wikis will remain restricted to collaborators, but with the
new setting exposed, they can be turned into globally editable wikis.
FixesCodeberg/Community#28.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 4b744399229f255eb124c22e3969715046043209)
(cherry picked from commit 337cf62c1094273ab61fbaab8e7fb41eb6e2e979)
(cherry picked from commit b6786fdb3246a3a455b59149943807c1f13a028a)
(cherry picked from commit a5d2829a1027afd593fd855a8e2d7d7cd38234b8)
[GITEA] Optionally allow anyone to edit Wikis (squash) AddTokenAuth
(cherry picked from commit fed50cf72eaaa00ef1f4730f9b12a64a10b66113)
(cherry picked from commit 42c55e494e1018a210e54d405c15eec24a0b37c7)
(cherry picked from commit e3463bda47ffee4ab57efadfe5094f9401541cfd)