This PR will avoid load pullrequest.Issue twice in pull request list
page. It will reduce x times database queries for those WIP pull
requests.
Partially fix#29585
---------
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 62f8174aa2fae1481c7e17a6afcb731a5b178cd0)
Conflicts:
models/activities/notification_list.go
moved to models/activities/notification.go
`CommitGPGSignature` was originally made to store information about a
commit's GPG signature. Nowadays, it is used to store information about
SSH signatures too, and not just commit signatures, but tag signatures
too.
As such, rename it to `ObjectSignature`, because that describes what it
does a whole lot better.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Because the `git` module did not recognize SSH signed tags, those
signatures ended up in the `notes` column of the `release` table. While
future signatures will not end up there, Forgejo should clean up the old
ones.
This migration does just that: finds all releases that have an SSH
signature, and removes those signatures, preserving the rest of the
note (if any).
While this may seem like an expensive operation, it's only done once,
and even on the largest known Forgejo instance as of this
writing (Codeberg), the number of affected rows are just over a hundred,
a tiny amount all things considered.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Fix#28157
This PR fix the possible bugs about actions schedule.
- Move `UpdateRepositoryUnit` and `SetRepoDefaultBranch` from models to
service layer
- Remove schedules plan from database and cancel waiting & running
schedules tasks in this repository when actions unit has been disabled
or global disabled.
- Remove schedules plan from database and cancel waiting & running
schedules tasks in this repository when default branch changed.
(cherry picked from commit 97292da960)
Conflicts:
modules/actions/github.go
routers/web/repo/setting/default_branch.go
routers/web/repo/setting/setting.go
services/repository/branch.go
services/repository/setting.go
tests/integration/actions_trigger_test.go
Repositories displaying an "Add more..." tab on the header is a neat way
to let people discover they can enable more units. However, displaying
it all the time for repository owners, even when they deliberately do
not want to enable more units gets noisy very fast.
As such, this patch introduces a new setting which lets people disable
this hint under the appearance settings.
Fixes#2378.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This PR do some loading speed optimization for feeds user interface
pages.
- Load action users batchly but not one by one.
- Load action repositories batchly but not one by one.
- Load action's Repo Owners batchly but not one by one.
- Load action's possible issues batchly but not one by one.
- Load action's possible comments batchly but not one by one.
(cherry picked from commit aed3b53abdd02a3ffbf9e8eb90272ff567333073)
Unlike other async processing in the queue, we should sync branches to
the DB immediately when handling git hook calling. If it fails, users
can see the error message in the output of the git command.
It can avoid potential inconsistency issues, and help #29494.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Regression of #2507, which switched the HEAD from `pr.GetGitRefName()`
to `pr.HeadCommitID` but it had to be `prInfo.HeadCommitID`. Resolves#2656
I was able to reproduce this locally with _some_ pull requests, haven't
been able to get a reproducer trough integration testing.
(cherry picked from commit 25b842df261452a29570ba89ffc3a4842d73f68c)
Conflicts:
routers/web/repo/wiki.go
services/repository/branch.go
services/repository/migrate.go
services/wiki/wiki.go
also apply to Forgejo specific usage of the refactored functions
Refactor the webhook logic, to have the type-dependent processing happen
only in one place.
---
1. An event happens
2. It is pre-processed (depending on the webhook type) and its body is
added to a task queue
3. When the task is processed, some more logic (depending on the webhook
type as well) is applied to make an HTTP request
This means that webhook-type dependant logic is needed in step 2 and 3.
This is cumbersome and brittle to maintain.
Updated webhook flow with this PR:
1. An event happens
2. It is stored as-is and added to a task queue
3. When the task is processed, the event is processed (depending on the
webhook type) to make an HTTP request
So the only webhook-type dependent logic happens in one place (step 3)
which should be much more robust.
- the raw event must be stored in the hooktask (until now, the
pre-processed body was stored)
- to ensure that previous hooktasks are correctly sent, a
`payload_version` is added (version 1: the body has already been
pre-process / version 2: the body is the raw event)
So future webhook additions will only have to deal with creating an
http.Request based on the raw event (no need to adjust the code in
multiple places, like currently).
Moreover since this processing happens when fetching from the task
queue, it ensures that the queuing of new events (upon a `git push` for
instance) does not get slowed down by a slow webhook.
As a concrete example, the PR #19307 for custom webhooks, should be
substantially smaller:
- no need to change `services/webhook/deliver.go`
- minimal change in `services/webhook/webhook.go` (add the new webhook
to the map)
- no need to change all the individual webhook files (since with this
refactor the `*webhook_model.Webhook` is provided as argument)
(cherry picked from commit 26653b196bd1d15c532af41f60351596dd4330bd)
Conflicts:
services/webhook/deliver_test.go
trivial context conflict
Fix#29000Fix#28685Fix#18568
Related: #27497
And by the way fix#24036, add a Cancel button there (one line)
(cherry picked from commit 5cddab4f74bbb307ddf13e458c7ac22f93b9283a)
The tests on migration tests failed but CI reports successfully
https://github.com/go-gitea/gitea/actions/runs/7364373807/job/20044685969#step:8:141
This PR will fix the bug on migration v283 and also the CI hidden
behaviour.
The reason is on the Makefile
`GITEA_ROOT="$(CURDIR)" GITEA_CONF=tests/mysql.ini $(GO) test
$(GOTESTFLAGS) -tags='$(TEST_TAGS)' $(MIGRATE_TEST_PACKAGES)` will
return the error exit code.
But
`for pkg in $(shell $(GO) list
code.gitea.io/gitea/models/migrations/...); do \
GITEA_ROOT="$(CURDIR)" GITEA_CONF=tests/mysql.ini $(GO) test
$(GOTESTFLAGS) -tags '$(TEST_TAGS)' $$pkg; \
done`
will not work.
This also fix#29602
(cherry picked from commit 45277486c2c6213b7766b1da708a991cdb1f3565)
Conflicts:
.github/workflows/pull-db-tests.yml
Makefile
models/migrations/v1_22/v283.go
models/migrations/v1_22/v286_test.go
models/migrations/v1_22/v287_test.go
already in Forgejo for the Makefile & CI logic but Gitea changes
otherwise rule
Follow #29522
Administrators should be able to set a user's email address even if the
email address is not in `EMAIL_DOMAIN_ALLOWLIST`
(cherry picked from commit 136dd99e86eea9c8bfe61b972a12b395655171e8)
Fix#27457
Administrators should be able to manually create any user even if the
user's email address is not in `EMAIL_DOMAIN_ALLOWLIST`.
(cherry picked from commit 4fd9c56ed09b31e2f6164a5f534a31c6624d0478)
Add two "HTMLURL" methods for PackageDescriptor.
And rename "FullWebLink" to "VersionWebLink"
(cherry picked from commit bf6502a8f7a2e9a2b64b43b7733316d863c9a768)
To avoid conflicting with User.GetDisplayName, because there is no data
type in template.
And it matches other methods like GetActFullName / GetActUserName
(cherry picked from commit 3f081d4b54261c1b4ee4f1df40c610fdd9581ef2)
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)
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.
(cherry picked from commit eedb8f41297c343d6073a7bab46e4df6ee297a90)
- Disable the CODEOWNERS feature for forked repositories, as it would
otherwise inadvertently request reviewers when for example a pull
request is opened against a forked repository to propose changes to an
existant pull request in the original repository.
- Adds integration test.
- Resolves#2525
- The content history table contains the content history of issues and
comments. For issues they are saved with an comment id of zero.
- If you want to check if the issue has an content history, it should
take into account that SQL has `comment_id = 0`, as it otherwise could
return incorrect results when for example the issue already has an
comment that has an content history.
- Fix the code of `HasIssueContentHistory` to take this into account, it
relied on XORM to generate the SQL from the non-default values of the
struct, this wouldn't generate the `comment_id = 0` SQL as `0` is the
default value of an integer.
- Remove an unncessary log (it's not the responsibility of `models`
code to do logging).
- Adds unit test.
- Resolves#2513
- The CODEOWNER feature relies on the changed files to determine which
reviewers should be added according to the `CODEOWNER` file.
- The current approach was to 'diff' between the base and head branch,
which seems logical but fail in practice when the pull request is out of
date with the base branch. Therefore it should instead diff between the
head branch and the merge base of the head and base branch, so only the
actual affected files by the pull requests are used, the same approach
is used by the diff of an unmerged pull request.
- Add integration testing (for the feature as well).
- Resolves#2458
This PR will also keep the consistent between list assigned users and
check assigned users.
(cherry picked from commit 98ab9445d1020c515c3c789f0b27d952903a2978)
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
Adds a new API `/repos/{owner}/{repo}/commits/{sha}/pull` that allows
you to get the merged PR associated to a commit.
---------
Co-authored-by: 6543 <6543@obermui.de>
(cherry picked from commit 0a426cc575734e5eff410d6a790f40473117f753)
- In order to determine if the "Add more..." tab should be shown, the
template has to know if the repository has all units enabled, this is
done in the repository header which can be shown for quite a lot of
pages (code, issues, projects, actions etc.)
- This was previously set in the `RepoRefByType` function, which would
be called by pages such as code, issues and releases, but it was not
being called for all pages such as actions, packages and wiki. Which
would in turn incorrectly show the "Add more..." button when it
shouldn't.
- Now call it from the template itself, so the value is 'always' loaded
when necessary.
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
`KeyID` is never set.
(cherry picked from commit 155269fa586c41a268530c3bb56349e68e6761d7)
Conflicts:
models/user/email_address.go
trivial context conflict
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>
RequestReview get deleted on review.
So we don't have to try to load them on comments.
broken out #28544
(cherry picked from commit 6fad2c874438275d3f69bb1cc223708bd2d27ff6)
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>
- I found this while doing some unrelated testing in Forgejo. It wasn't
my intention to log failed SQL queries if they were cancelled (which can
happen quite frequently for larger instances) as in those cases it's not
interesting to know which SQL query was run. My intentation was only to
log an SQL query if there was an error reported by the database.
- Ref #2140
Commit 360b3fd17c (Include username in email headers (#28981),
2024-02-03) adds usernames to the From field of notification emails in
the form of `Display Name (@username)`, to prevent spoofing. However,
some email filtering software flags "@" in the display name part of the
From field as potential spoofing, as you could set the display name part
to another email address than the one you are sending from (e.g.
`From: "apparent@email-address" <actual@email-address>`). To avoid
being flagged, instead send emails from `Display Name (username)`.
Closes: #29107
---------
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 5b2fd0fc19a2a77414c8e2989b4794b6617221f5)
The parameter extraConfigs has never been used anywhere. This PR just
removed it. It can be taken back once it's needed.
(cherry picked from commit 8c6ffdac378654f9d2171ebdbc46becf1571f7fe)
* Split TestPullRequest out of AddTestPullRequestTask
* Before scheduling the task, AddTestPullRequestTask stores the max
index of the repository
* When the task runs, it does not take into account pull requests that
have an index higher than the recorded max index
When AddTestPullRequestTask is called with isSync == true, it is the
direct consequence of a new commit being pushed. Forgejo knows nothing
of this new commit yet. If a PR is created later and its head
references the new commit, it will have an index that is higher and
must not be taken into account. It would be acting and triggering a
notification for a PR based on an event that happened before it
existed.
Refs: https://codeberg.org/forgejo/forgejo/issues/2009
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/2236
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Earl Warren <contact@earl-warren.org>
Co-committed-by: Earl Warren <contact@earl-warren.org>
(cherry picked from commit b3be895a30b32bfae4acfa32db54406e1dd1dc21)
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)
So the caller can check log events at the desired level instead of
being limited to the default level log.INFO
(cherry picked from commit 2fbf5f9555641a1244576df92cb518f8ad76c162)
(cherry picked from commit e2137a3147389114475db787522d5c22ff249d2c)
- Fix typo in the slow query threshold setting, add a deprecation warning.
- Resolves#2203
(cherry picked from commit 02f6608e5fc21a0a00da5fc4c99152d43ee2ea4d)
(cherry picked from commit 4e8f6b2ffdb25e0257933ee0a1bd21e3f4e86740)
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)
When searching for repository topics, either via the API, or via
Explore, paging did not work correctly, because it only applied when the
`page` parameter was non-zero. Paging should have applied when the page
size is greater than zero, which is what this patch does.
As a result, both the API, and the Explore endpoint will return paged
results (30 by default). As such, when managing topics on the frontend,
the offered completions will also be limited to a pageful of results,
based on what the user has already typed.
This drastically reduces the amount of traffic, and also the number of
the topics to choose from, and thus, the rendering time too.
The topics will be returned by popularity, with most used topics first.
A single page will contain `[api].DEFAULT_PAGING_NUM` (30 by default)
items that match the query. That's plenty to choose from.
Fixes#132.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 64d4ff41dbab7b3b84571b595158c3b451f53af7)
(cherry picked from commit 06b808fa2c0ddd52ca4569157892a0c7fc154b1f)
(cherry picked from commit 9205c9266a7d2b058100d03f5f3272f670f35866)
(cherry picked from commit 47863d4f724e7d2465acd6fca91e98157c60a29b)
- When the database returns an error about the SQL query, the error is
logged but not the SQL query and arguments, which is just as valuable as
the vague deeply hidden documented error that the database returns.
It's possible to log the SQL query by logging **all** SQL queries. For
bigger instances such as Codeberg, this is not a viable option.
- Adds a new hook, enabled by default, to log SQL queries with their
arguments and the error returned by the database when the database
returns an error.
- This likely needs some fine tuning in the future to decide when to
enable this, as the error is already logged and if people have the
`[database].LOG_SQL` option enabled, the SQL would be logged twice. But
given that it's an rare occurence for SQL queries to error, it's fine to
leave that as-is.
- Ref: https://codeberg.org/forgejo/forgejo/issues/1998
(cherry picked from commit 866229bc323619bc8686bad99951f95d5d46fe19)
(cherry picked from commit 96dd3e87cf5f75ac33bfad647e44852667c307d0)
(cherry picked from commit e165510317b3fe3be4fe49ad3ff0a055e7a92124)
(cherry picked from commit 1638e2b3f56a508dbf218207bf0c3c4d16493255)
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)
(cherry picked from commit b005b586c354119d2b6aaf6e4c18eb3f1ddfb615)
(cherry picked from commit 0077b2661e7e5be7b2e3772113abeb401f4085d5)
(cherry picked from commit c4589d1fce5eac383dd8530427140183a7aeff46)
(cherry picked from commit a7f9ff982c0c14e9484561e194d4fa7c5d80a76b)
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)
- Rewrite `UpdateCommentsMigrationsByType` to not use `WHERE IN` as
that's a performance diaster for MariaDB, it now use batching to query
the the relevant comment IDs via JOINs (which is not possible in a
UPDATE query for SQLite) and then update them in a seperate query.
- Add unit test.
- Resolves https://codeberg.org/forgejo/forgejo/issues/1856
(cherry picked from commit 8098ca9d2e391b17e5e3da5cfa5af042221bfe36)
Conflicts:
models/issues/comment.go
https://codeberg.org/forgejo/forgejo/pulls/2075
(cherry picked from commit ca65deba1cc183ce1643ee6a1f698c5ecb2ac571)
(cherry picked from commit 0e1e09e77dd1bc82b1eae02147fddca1d9954469)
(cherry picked from commit 19013ba5eac756044e6307abee6fb5d6709c855d)
(cherry picked from commit 23c887f97eeb08ee2a318b28878edb488428f98d)
(cherry picked from commit b3321d1a847373acba5b1f620191edc38a69ccbe)
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)
- If the session doesn't exist, it shouldn't be expected that the
variable is non-nil. Define the session variable instead and insert that.
- Add unit tests to test the behavior of the database sessions code .
- Regression caused by dd30d9d5c0.
- Resolves https://codeberg.org/forgejo/forgejo/issues/2042
(cherry picked from commit 90307ad2004a9a9ddda30af4038224fedf0e6ca3)
(cherry picked from commit 874ef1978d7db5e8ba1482d4c8190b914fa110b3)
(cherry picked from commit 27d5f035fc744d932d1e4c95c55d98479fccf368)
(cherry picked from commit 65dbc4303ba8afdef70c573aaf782b76aaf0bbad)
[GITEA] Fix session generation for database (squash) timeutil.Mock
because of e743570f65 * Refactor timeutil package (#28623)
(cherry picked from commit acc6b51be2b6d676129f653a8949b2c06aa2ad94)
(cherry picked from commit 02b74317f2d8120a705599d6ae908634a1fa2b44)
(cherry picked from commit 63b9b624bd203b7b5eff7439dbc09eeb9bc52ade)
(cherry picked from commit 7752ff8baa525918e00193606048e3c2dd5a4999)
(cherry picked from commit c0af4d943854ce3a77eaa75c06b04394301f45c4)
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 aaaece28e4c6a8980cef932e224e84933d7c9262)
(cherry picked from commit 639dafabec0a5c1f943b44ca02f72c5ba2fc5e10)
(cherry picked from commit d699c12cebea7dbbda950ae257a46d53c39f22ea)
[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 43ded8ee30ab5c7a40a456600cdaa8a0fbdccec2)
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 e35d2af2e56f4ecb3a4f6d1109d02c8aa1a6d182)
(cherry picked from commit 03989418a70d3445e0edada7fbe5a4151d7836b1)
(cherry picked from commit f50e0dfe5e90d6a31c5b59e687580e8b2725c22b)
(cherry picked from commit cad9184a3653e6c80de2e006a0d699b816980987)
(cherry picked from commit e2da5d7fe13a685606913a131687a94f9f5fcfeb)
(cherry picked from commit 3a80534d4db523efe56b368489f81dc1cb2c99f7)
Similar to how some other parts of the web UI support a `/latest` path
to directly go to the latest of a certain thing, let the Actions web UI
do the same: `/{owner}/{repo}/actions/runs/latest` will redirect to the
latest run, if there's one available.
Fixes gitea#27991.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit f67ccef1dd3146b0b942a94e2482b37595180e91)
Code cleanup in the actions.ViewLatest route handler
Based on feedback received after the feature was merged, use
`ctx.NotFound` and `ctx.ServerError`, and drop the use of the
unnecessary `ctx.Written()`.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 74e42da5630f9148faaf6b03bf1ac5724fa86b25)
(cherry picked from commit f7535a1cef96ce0589f37907f88b024cd095d0ac)
(cherry picked from commit 1a90cd37c31a1b9c770d6d79a4663ed8d67845c0)
(cherry picked from commit d86d71340afd372e5b5083d5563c2f5b48d975e6)
(cherry picked from commit 9e5cce1afccebcd6146e5e0d364bfdbb840b5276)
(cherry picked from commit 2013fb3fab5e23d0088434d835411f26a3fd9905)
(cherry picked from commit 88b9d21d1194abd133c3b4cbaa19792da433cb43)
(cherry picked from commit 72c020298eebcb0c90e23e7ff35e37be867afc44)
(cherry picked from commit 6525f730dfdd7cb412762d9e30348801335d17ee)
This adds a new `doctor` check: `fix-push-mirrors-without-git-remote`. The new check looks for push mirrors that do not have their remotes configured in git. If automatic fixing is enabled, it will remove these push mirrors from the database.
The check is not run by default, and thus, must be invoked manually. It should be usable in a half-migrated state, too, and as such, fixes#1800.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/1853
Co-authored-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Co-committed-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 9038e07ef35978336612588d68c1315179a45c73)
(cherry picked from commit b15bafcbc7d9033b0cc7b0fd888915b117e08d42)
(cherry picked from commit 93ba05a2dd9fdec46f337542cd5f22c8960ac55f)
(cherry picked from commit e418ea80822361e387b460c583592bbd83d4a39e)
(cherry picked from commit 321790a91ec8553d1b3668f606ebec762865dd17)
(cherry picked from commit f4e19d332392cb455b3b4e32e271f3e42302bbc8)
(cherry picked from commit 4d9923dee851a4046050761d3dd352f2f343f4fc)
(cherry picked from commit 049df69eda1ceb47f6e74c9a67e9ce5041e65c3b)
Conflicts:
services/doctor/push_mirror_consistency.go
https://codeberg.org/forgejo/forgejo/pulls/2214
(cherry picked from commit c79cba8d556320be0da7ca8324b39cd8930465bf)
(cherry picked from commit f3a3969c02cade7261a5f25c9e342800ccdf9111)
- Add a dropdown to the web interface for changing files to select which
Email should be used for the commit. It only shows (and verifies) that a
activated mail can be used, while this isn't necessary, it's better to
have this already in place.
- Added integration testing.
- Resolves https://codeberg.org/forgejo/forgejo/issues/281
(cherry picked from commit 564e701f407c0e110f3c7a4102bf7ed7902b815f)
(cherry picked from commit de8f2e03cc7d274049dd6a849b3d226968782644)
(cherry picked from commit 0182cff12ed4b68bd49ebc2b9951d9a29f7a36ca)
(cherry picked from commit 9c74254d4606febd702315c670db4fb6b14040a1)
(cherry picked from commit 2f0b68f821ae53dd12b496cc660353d5bf7cd143)
(cherry picked from commit 079b995d49ba7a625035fe9ec53741f6b0112007)
(cherry picked from commit 6952ea6ee3de8157d056c4381de7529de6eaef7b)
(cherry picked from commit 6c7d5a5d140152be80ec38a979a2a7b704ce653a)
(cherry picked from commit 49c39f0ed5a011b26f2e33f35811bb31fab3cf64)
(cherry picked from commit a8f9727388192c6c22b2f8cbbae15a96203ec3b6)
Fix gitlab migration unit test
Closes#1837.
The differences in dates can be explained by commit e19b9653ea, which
changed the order in which "created_date" and "updated_date" are
considered.
(cherry picked from commit b0bba20aa44e30ef0296b89f336d426224d73a16)
Mock HTTP requests in GitLab migration test
This introduces a new utility which can be added to other tests
making HTTP calls to a live service, to cache the responses of this
service in the repository.
(cherry picked from commit 52053b138948bd74c7eb88c0796c2e18f4247f3c)
Enable mocked HTTP responses for GitLab migration test
(cherry picked from commit 19cefc4de24b935a6a5c92be8360301f196f3aa5)
Simplify HTTP mocking utility in unit tests
Follow-up to https://codeberg.org/forgejo/forgejo/pulls/1841
(cherry picked from commit ca517c8bb4bf97f061b8b19fd3303d734f46660c)
(cherry picked from commit b227e0dd6bdf2dc3e8679443fc538fbce4b3bcf5)
(cherry picked from commit 6cc9d06556cda6c952a0542284fbe504114971ce)
(cherry picked from commit f0746e648dc30510d655b8a3b821199b2638800f)
(cherry picked from commit 414193341b8493723c16694789cbc08dc80b9ce5)
(cherry picked from commit 6e93df3bbb6c589502afc9dc74a7ae1a7c0f7da8)
(cherry picked from commit db0dbab5527c9f1783fd0eddb057c2d91cbb67e4)
(cherry picked from commit 8f9c9c63fbd3f266bb29d38791e83dc369cc1350)
(cherry picked from commit e74e26203095b675ccedbc2e166faed59369d467)
(cherry picked from commit 2e0933edcfa102b578fb3c2500f9e6af9e5ba1c7)
(cherry picked from commit 65060c69616631221d3dd9ef8b48fbcb007ad0c6)
