- 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
---------
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)
The issue filter links should not be crawled by search engines, because
they they only filter results, and contain nothing new, yet, they put a
considerable load on the server.
To stop - well behaving - search engines from following these links, add
a `rel="nofollow"` property to them. The same property is already
present on the archive download links, and plenty of other places.
Fixes#2361.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
There are a few inconsistencies within Gitea and this PR addresses one of them.
This PR updates the sign-in page layout, including the register and openID tabs,
to match the layout of the settings pages (`/user/settings`) for more consistency.
**Before**
<img width="968" alt="Screenshot 2024-02-05 at 8 27 24 AM"
src="https://github.com/go-gitea/gitea/assets/6152817/fb0cb517-57c0-4eed-be1d-56f36bd1960d">
**After**
<img width="968" alt="Screenshot 2024-02-05 at 8 26 39 AM"
src="https://github.com/go-gitea/gitea/assets/6152817/428d691d-0a42-4a67-a646-05527f2a7b41">
---------
Co-authored-by: rafh <rafaelheard@gmail.com>
(cherry picked from commit 1c14cd0c43d670fef984068e2666641ea5a062db)
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
If a repository administrator is viewing a repository, and there are
units that can be enabled, display an "Add more..." link that leads to
the repository unit settings page.
The goal here is to allow instances to configure a small set of repo
units to be enabled by default, but also highlight for repo admins that
they can add more.
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>
- Use maintained fork https://github.com/golangci/misspell
- Rename `mispell-check` to `lint-spell`, add `lint-spell-fix`
- Run `lint-spell` in separate actions step
- Lint more files, fix discovered issues
- Remove inaccurate and outdated info in docs (we do not need GOPATH for
tools anymore)
Maybe later we can add more spellchecking tools, but I have not found
any good ones yet.
(cherry picked from commit 9c39f8515fa88d644736c6773d7a05d070a02e82)
Conflicts:
.github/workflows/pull-compliance.yml
Makefile
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 0ca118fdc3)
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 d87c526d2a)
- When a commit references a pull request, the detail strings should
reflect that. Add a new translation string for the pull request.
- Added integration tests.
- Resolves#2256
(cherry picked from commit 0d054cd4d9)
- When there's a succesful POST operation, it should return a 201 status
code (which is the status code for succesful created) and additionally
the created object.
- Currently for the `POST /repos/{owner}/{repo}/tags` endpoint an 200
status code was documented in the OpenAPI specification, while an 201
status code was actually being returned. In this case the code is
correct and the documented status code needs to be adjusted.
- Resolves#2200
(cherry picked from commit a2939116f5)
(cherry picked from commit 22cff41585)
(cherry picked from commit b23a7f27bb)
When comparing branches, only offer those branches to use as a base
where the repository allows pull requests. Those that do not allow pull
request would result in a 404, so offering them as an option would be
misleading.
Refs: https://codeberg.org/forgejo/forgejo/pulls/2194
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 022d0e0d71)
(cherry picked from commit 957990b36a)
(cherry picked from commit 6d2df72825)
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 a29f10661d)
(cherry picked from commit 70c5e2021d)
(cherry picked from commit 48b25be67a)
- The name could be conflucted with the `GET
/user/applications/oauth2/{id}` operation, as it only differed in a
single letter being uppercase. Change it to be
userGetOAuth2Application**s**, as that's also more accurate for this function.
- Resolves#2163
(cherry picked from commit 1891dac547)
(cherry picked from commit 68fceb9b7a)
(cherry picked from commit 7335d6de54)
- Document the correct content types for Git archives. Add code that
actually sets the correct application type for `.zip` and `.tar.gz`.
- When an action (POST/PUT/DELETE method) was successful, an 204 status
code should be returned instead of status code 200.
- Add and adjust integration testing.
- Resolves#2180
- Resolves#2181
(cherry picked from commit 6c8c4512b5)
(cherry picked from commit 3f74bcb14d)
(cherry picked from commit 6ed9057fd7)
The message telling us that we recently pushed on a branch should
include a link to said branch, not just a "New pull request" button.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit d9662d03a4)
(cherry picked from commit 2527e09125)
(cherry picked from commit 0ddefdf9f4)
(cherry picked from commit e9ff354f7c)
Refs: https://codeberg.org/forgejo/forgejo/issues/2109
(cherry picked from commit 8b4ba3dce7)
(cherry picked from commit 196edea0f9)
[GITEA] POST /repos/{owner}/{repo}/pulls/{index}/reviews/{id}/comments (squash) do not implicitly create a review
If a comment already exists in a review, the comment is added. If it
is the first comment added to a review, it will implicitly create a
new review instead of adding to the existing one.
The pull_service.CreateCodeComment function is responsibe for this
behavior and it will defer to createCodeComment once the review is
determined, either because it was found or because it was created.
Rename createCodeComment into CreateCodeCommentKnownReviewID to expose
it and change the API endpoint to use it instead. Since the review is
provided by the user and verified to exist already, there is no need
for the logic implemented by CreateCodeComment.
The tests are modified to remove the initial comment from the fixture
because it was creating the false positive. I was verified to fail
without this fix.
(cherry picked from commit 6a555996dc)
(cherry picked from commit b173a0ccee)
(cherry picked from commit 838ab9740a)
- Remove `container` to remove unnecessary margins being added to the
whole page.
- Specify max width for the 404 image to avoid overflow of the image.
(cherry picked from commit b1ced72ce5)
(cherry picked from commit ef5e1b01b8)
(cherry picked from commit c321af3d5f)
(cherry picked from commit d6e99436b5)
Expose the repository flags feature over the API, so the flags can be
managed by a site administrator without using the web API.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit bac9f0225d)
(cherry picked from commit e7f5c1ba14)
(cherry picked from commit 95d9fe19cf)
(cherry picked from commit 7fc51991e4)
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 ba735ce222)
(cherry picked from commit f09f6e029b)
(cherry picked from commit 2f8b041489)
(cherry picked from commit d3186ee5f4)
Files can have an RSS feed, but those only make sense when taken in the
context of a branch. There is no history to make a feed of on a tag or a
commit: they're static. Forgejo does not provide a feed for them for
this reason.
However, the file view on the web UI was offering a link to these
non-existent feeds. With this patch, it does that no longer, and only
provides a link when viewing the file in the context of a branch.
Fixes#2102.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 4b48d21ea7)
(cherry picked from commit 70cb266760)
(cherry picked from commit 69b45c3fea)
Conflicts:
options/locale/locale_en-US.ini
https://codeberg.org/forgejo/forgejo/pulls/2249
(cherry picked from commit 639a2c0741)
Adds `[repository].DOWNLOAD_OR_CLONE_METHODS` (defaulting to
"download-zip,download-targz,download-bundle,vscode-clone"), which lets
an instance administrator override the additional clone methods
displayed on the repository home view.
This is purely display-only, the clone methods not listed here are still
available, unless disabled elsewhere. They're just not displayed.
Fixes#710.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 2aadcf4946)
(cherry picked from commit 42ac34fbf9)
(cherry picked from commit bd231b0245)
(cherry picked from commit 3d3366dbbe)
(cherry picked from commit 0157fb9b88)
(cherry picked from commit bee88f6a83)
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 4b74439922)
(cherry picked from commit 337cf62c10)
(cherry picked from commit b6786fdb32)
(cherry picked from commit a5d2829a10)
[GITEA] Optionally allow anyone to edit Wikis (squash) AddTokenAuth
(cherry picked from commit fed50cf72e)
(cherry picked from commit 42c55e494e)
(cherry picked from commit e3463bda47)
During registration, one may be required to give their email address, to
be verified and activated later. However, if one makes a mistake, a
typo, they may end up with an account that cannot be activated due to
having a wrong email address.
They can still log in, but not change the email address, thus, no way to
activate it without help from an administrator.
To remedy this issue, lets allow changing the email address for logged
in, but not activated users.
This fixes gitea#17785.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit aaaece28e4)
(cherry picked from commit 639dafabec)
(cherry picked from commit d699c12ceb)
[GITEA] Allow changing the email address before activation (squash) cache is always active
This needs to be revisited because the MailResendLimit is not enforced
and turns out to not be tested.
See e7cb8da2a8 * Always enable caches (#28527)
(cherry picked from commit 43ded8ee30)
Rate limit pre-activation email change separately
Changing the email address before any email address is activated should
be subject to a different rate limit than the normal activation email
resending. If there's only one rate limit for both, then if a newly
signed up quickly discovers they gave a wrong email address, they'd have
to wait three minutes to change it.
With the two separate limits, they don't - but they'll have to wait
three minutes before they can change the email address again.
The downside of this setup is that a malicious actor can alternate
between resending and changing the email address (to something like
`user+$idx@domain`, delivered to the same inbox) to effectively halving
the rate limit. I do not think there's a better solution, and this feels
like such a small attack surface that I'd deem it acceptable.
The way the code works after this change is that `ActivatePost` will now
check the `MailChangeLimit_user` key rather than `MailResendLimit_user`,
and if we're within the limit, it will set `MailChangedJustNow_user`. The
`Activate` method - which sends the activation email, whether it is a
normal resend, or one following an email change - will check
`MailChangedJustNow_user`, and if it is set, it will check the rate
limit against `MailChangedLimit_user`, otherwise against
`MailResendLimit_user`, and then will delete the
`MailChangedJustNow_user` key from the cache.
Fixes#2040.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit e35d2af2e5)
(cherry picked from commit 03989418a7)
(cherry picked from commit f50e0dfe5e)
(cherry picked from commit cad9184a36)
(cherry picked from commit e2da5d7fe1)
(cherry picked from commit 3a80534d4d)
