Instead of repeating the tests that verify the ID of a comment
is related to the repository of the API endpoint, add the middleware
function commentAssignment() to assign ctx.Comment if the ID of the
comment is verified to be related to the repository.
There already are integration tests for cases of potential unrelated
comment IDs that cover some of the modified endpoints which covers the
commentAssignment() function logic.
* TestAPICommentReactions - GetIssueCommentReactions
* TestAPICommentReactions - PostIssueCommentReaction
* TestAPICommentReactions - DeleteIssueCommentReaction
* TestAPIEditComment - EditIssueComment
* TestAPIDeleteComment - DeleteIssueComment
* TestAPIGetCommentAttachment - GetIssueCommentAttachment
The other modified endpoints do not have tests to verify cases of
potential unrelated comment IDs. They no longer need to because they
no longer implement the logic to enforce this. They however all have
integration tests that verify the commentAssignment() they now rely on
does not introduce a regression.
* TestAPIGetComment - GetIssueComment
* TestAPIListCommentAttachments - ListIssueCommentAttachments
* TestAPICreateCommentAttachment - CreateIssueCommentAttachment
* TestAPIEditCommentAttachment - EditIssueCommentAttachment
* TestAPIDeleteCommentAttachment - DeleteIssueCommentAttachment
(cherry picked from commit d414376d749041da1be288c02fdaa24fddeafd5c)
(cherry picked from commit 09db07aeaed167edc66cb832b0aa54b31d14f0d8)
(cherry picked from commit f44830c3cba0b9416505a2b0b560cfa096ffeb7c)
Conflicts:
modules/context/api.go
https://codeberg.org/forgejo/forgejo/pulls/2249
(cherry picked from commit 9d1bf7be15420ce4ca6e92a8bd048d483172de3b)
Refs: https://codeberg.org/forgejo/forgejo/issues/2109
(cherry picked from commit 8b4ba3dce7fc99fa328444ef27383dccca49c237)
(cherry picked from commit 196edea0f972a9a027c4cacb9df36330cf676d2f)
[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 6a555996dca6ba71c65818e14ab0eeafa1af6dc2)
(cherry picked from commit b173a0ccee6cc0dadf40ec55e5d88987314c1cc4)
(cherry picked from commit 838ab9740a6b022676103bcb3a7d168b501006e1)
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 bac9f0225d47e159afa90e5bbea9562cbc860dae)
(cherry picked from commit e7f5c1ba141ac7f8c7834b5048d0ffd3ce50900b)
(cherry picked from commit 95d9fe19cf3ed5787855ac2a442d29104498aa36)
(cherry picked from commit 7fc51991e405ea8d44fd6b4b4de13ad65da63ae7)
- Switch the supported schemas for the Swagger API around, such that
https is the first one listed. This ensures that when the Swagger API is
used it will default to the https schema, which is likely the schema you
want to use in the majority of the cases.
- Resolves#1895
BREAKING CHANGE NOTICE:
If you are using the Swagger API JSON directly to communicate with the
Forgejo API, the library you are using may be using the first schema
defined in the JSON file (e.g. https://code.forgejo.org/swagger.v1.json)
to construct the request url, this used to be `http` but has now changed
to `https`. This can cause failures if you want to send the swagger
request over `http` (and there is no HTTPS redirection configured).
(cherry picked from commit 81e5f438868192e9cca46824ceb3db787bdd8629)
(cherry picked from commit d847469ea278e77ed4fd6147dd54025ce222ebc9)
(cherry picked from commit 96e75e1d5ca97cd4c668fc60d444dc91c98e83a6)
(cherry picked from commit 65baa6426109403f0b8a779b061f7733d8034ba7)
(cherry picked from commit cd3e0a74e6a7bb90da6f069b7fea0796d5f3d775)
(cherry picked from commit a3127e90b21660d1d7efb6dd536f5fb5619d3307)
(cherry picked from commit 2b22272dc588ee6c2c4081b087f5b87b82ac52c8)
(cherry picked from commit 7363790592b10c4fc52266fd0c33ed79454cd276)
(cherry picked from commit 432b9a4451997742df50d3db33285f2dd5ea0bef)
Refs: https://codeberg.org/forgejo/forgejo/pulls/2222
(cherry picked from commit 5f837efc15f3d1e0d7fbed7fc569251143266584)
fix: write xml header
(cherry picked from commit a715984a42be9da81c48106d5eae244098ac1108)
fix: optional elements and xml schema
(cherry picked from commit 6ea6895a3616246e7282aa20d8f010fa931b60ea)
fix: pass all other requests to file search
(cherry picked from commit 9bfc74833a3b657453b4519573598432a87e3e3c)
test: add integration test
(cherry picked from commit b798f4ce86daa78e694c5c142e6f5f44938e6cb6)
fix: use xmlResponse
(cherry picked from commit 7f76df0b246c64fac0eeb115642c8cb6eb676f36)
(cherry picked from commit e18d574ca40905aec52fbbe8247ba83fd01874dd)
This field adds the possibility to set the update date when modifying
an issue through the API.
A 'NoAutoDate' in-memory field is added in the Issue struct.
If the update_at field is set, NoAutoDate is set to true and the
Issue's UpdatedUnix field is filled.
That information is passed down to the functions that actually updates
the database, which have been modified to not auto update dates if
requested.
A guard is added to the 'EditIssue' API call, to checks that the
udpate_at date is between the issue's creation date and the current
date (to avoid 'malicious' changes). It also limits the new feature
to project's owners and admins.
(cherry picked from commit c524d33402c76bc4cccea2806f289e08a009baae)
Add a SetIssueUpdateDate() function in services/issue.go
That function is used by some API calls to set the NoAutoDate and
UpdatedUnix fields of an Issue if an updated_at date is provided.
(cherry picked from commit f061caa6555e0c9e922ee1e73dd2e4337360e9fe)
Add an updated_at field to the API calls related to Issue's Labels.
The update date is applied to the issue's comment created to inform
about the modification of the issue's labels.
(cherry picked from commit ea36cf80f58f0ab20c565a8f5d063b90fd741f97)
Add an updated_at field to the API call for issue's attachment creation
The update date is applied to the issue's comment created to inform
about the modification of the issue's content, and is set as the
asset creation date.
(cherry picked from commit 96150971ca31b97e97e84d5f5eb95a177cc44e2e)
Checking Issue changes, with and without providing an updated_at date
Those unit tests are added:
- TestAPIEditIssueWithAutoDate
- TestAPIEditIssueWithNoAutoDate
- TestAPIAddIssueLabelsWithAutoDate
- TestAPIAddIssueLabelsWithNoAutoDate
- TestAPICreateIssueAttachmentWithAutoDate
- TestAPICreateIssueAttachmentWithNoAutoDate
(cherry picked from commit 4926a5d7a28581003545256632213bf4136b193d)
Add an updated_at field to the API call for issue's comment creation
The update date is used as the comment creation date, and is applied to
the issue as the update creation date.
(cherry picked from commit 76c8faecdc6cba48ca4fe07d1a916d1f1a4b37b4)
Add an updated_at field to the API call for issue's comment edition
The update date is used as the comment update date, and is applied to
the issue as an update date.
(cherry picked from commit cf787ad7fdb8e6273fdc35d7b5cc164b400207e9)
Add an updated_at field to the API call for comment's attachment creation
The update date is applied to the comment, and is set as the asset
creation date.
(cherry picked from commit 1e4ff424d39db7a4256cd9abf9c58b8d3e1b5c14)
Checking Comment changes, with and without providing an updated_at date
Those unit tests are added:
- TestAPICreateCommentWithAutoDate
- TestAPICreateCommentWithNoAutoDate
- TestAPIEditCommentWithAutoDate
- TestAPIEditCommentWithNoAutoDate
- TestAPICreateCommentAttachmentWithAutoDate
- TestAPICreateCommentAttachmentWithNoAutoDate
(cherry picked from commit da932152f1deb3039a399516a51c8b6757059c91)
Pettier code to set the update time of comments
Now uses sess.AllCols().NoAutoToime().SetExpr("updated_unix", ...)
XORM is smart enough to compose one single SQL UPDATE which all
columns + updated_unix.
(cherry picked from commit 1f6a42808dd739c0c2e49e6b7ae2967f120f43c2)
Issue edition: Keep the max of the milestone and issue update dates.
When editing an issue via the API, an updated_at date can be provided.
If the EditIssue call changes the issue's milestone, the milestone's
update date is to be changed accordingly, but only with a greater
value.
This ensures that a milestone's update date is the max of all issue's
update dates.
(cherry picked from commit 8f22ea182e6b49e933dc6534040160dd739ff18a)
Rewrite the 'AutoDate' tests using subtests
Also add a test to check the permissions to set a date, and a test
to check update dates on milestones.
The tests related to 'AutoDate' are:
- TestAPIEditIssueAutoDate
- TestAPIAddIssueLabelsAutoDate
- TestAPIEditIssueMilestoneAutoDate
- TestAPICreateIssueAttachmentAutoDate
- TestAPICreateCommentAutoDate
- TestAPIEditCommentWithDate
- TestAPICreateCommentAttachmentAutoDate
(cherry picked from commit 961fd13c551b3e50040acb7c914a00ead92de63f)
(cherry picked from commit d52f4eea44692ee773010cb66a69a603663947d5)
(cherry picked from commit 3540ea2a43155ca8cf5ab1a4a246babfb829db16)
Conflicts:
services/issue/issue.go
https://codeberg.org/forgejo/forgejo/pulls/1415
(cherry picked from commit 56720ade008c09122d825959171aa5346d645987)
Conflicts:
routers/api/v1/repo/issue_label.go
https://codeberg.org/forgejo/forgejo/pulls/1462
(cherry picked from commit 47c78927d6c7e7a50298fa67efad1e73723a0981)
(cherry picked from commit 2030f3b965cde401976821083c3250b404954ecc)
(cherry picked from commit f02aeb76981cd688ceaf6613f142a8a725be1437)
Conflicts:
routers/api/v1/repo/issue_attachment.go
routers/api/v1/repo/issue_comment_attachment.go
https://codeberg.org/forgejo/forgejo/pulls/1575
(cherry picked from commit d072525b35e44faf7ff87143c0e52b8ba8a625c8)
(cherry picked from commit 8424d0ab3df75ac3ffa30f42d398e22995ada5e7)
(cherry picked from commit 5cc62caec788b54afd9da5b9193ce06ee8ec562b)
(cherry picked from commit d6300d5dcd01c7ddc65d8b0f326f9c19cb53b58e)
[FEAT] allow setting the update date on issues and comments (squash) apply the 'update_at' value to the cross-ref comments (#1676)
[this is a follow-up to PR #764]
When a comment of issue A referencing issue B is added with a forced 'updated_at' date, that date has to be applied to the comment created in issue B.
-----
Comment:
While trying my 'RoundUp migration script', I found that this case was forgotten in PR #764 - my apologies...
I'll try to write a functional test, base on models/issues/issue_xref_test.go
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/1676
Co-authored-by: fluzz <fluzz@freedroid.org>
Co-committed-by: fluzz <fluzz@freedroid.org>
(cherry picked from commit ac4f727f63a2dd746dd84a31ebf7f70d5b5d7c52)
(cherry picked from commit 5110476ee9010ba8cdca0e0f37f765f8800e9fe1)
(cherry picked from commit 77ba6be1dab4f6f3678d79a394da56e6447ebbe1)
(cherry picked from commit 9c8337b5c442cfd72d97597c2089e776f42828b7)
(cherry picked from commit 1d689eb686f0f7df09c7861b3faf9d8683cb933b)
(cherry picked from commit 511c519c875a4c4e65c02ef0c4e3b941f4da4371)
(cherry picked from commit 2f0b4a8f610837d34844bb79cda1360ab23b6b1c)
(cherry picked from commit fdd4da111c449322901a0acf6d0857eac4716581)
[FEAT] allow setting the update date on issues and comments (squash) do not use token= query param
See https://codeberg.org/forgejo/forgejo/commit/33439b733a
(cherry picked from commit c5139a75b9e4af612a628171bd4f63a24860c272)
(cherry picked from commit c7b572c35d3e9e22017fd74045bcdc1109bd06df)
(cherry picked from commit aec7503ff6dd177980f3d9f367122ffc2fec8986)
(cherry picked from commit 87c65f2a490faeccb85088fa0981dd50f7199eb8)
(cherry picked from commit bd47ee33c20e53ae616a7e53d63c3b51809585fb)
(cherry picked from commit f3dbd90a747c14fb1b5b4271db6c10abbf86d586)
(cherry picked from commit 20b56692693e054bb3c04b4ef12b29b0715b4530)
(cherry picked from commit 1574643a6a9634e5b92c033a4bfb69062a86bd05)
Update semantic version according to specification
(cherry picked from commit 22510f41306f9c133a7e99b61f9c38dabfd4b810)
Mise à jour de 'Makefile'
(cherry picked from commit c3d85d8409f1bb18a45659a167cf1ffee057f3b6)
(cherry picked from commit 5ea23098513c068444226af41faf9be9c4c998e6)
(cherry picked from commit ec5217b9d1b94bb04e34ce8c27eecbdc6f3a247a)
(cherry picked from commit 14f08e364b2ad7e3176b45d3ec8da5f5605b4315)
(cherry picked from commit b4465c67b8737aed9fd79a43046aa3795a298e68)
[API] [SEMVER] replace number with version
(cherry picked from commit fba48e64977a75e77c9c6cf8e3f8a679a5e7b733)
(cherry picked from commit 532ec5d8782703b62d7d02312764e50637cd016e)
[API] [SEMVER] [v1.20] less is replaced by css
(cherry picked from commit 01ca3a4f4291cf4c62df42cbd12a00638f3cdc70)
(cherry picked from commit 1d928c3ab2e1fda6082e1400d89ea96d6605ebaa)
(cherry picked from commit a39dc804cd1da86444ed709455857f069475e7db)
Conflicts:
webpack.config.js
(cherry picked from commit adc68578b3eb41215338125edfca91804706f8a1)
(cherry picked from commit 9b8d98475fd7efcc15bf0d91b0af6ef3aff64508)
(cherry picked from commit 25161039745a63282257eded9616390241af8013)
(cherry picked from commit 18e6287963a0e1863cd08fd514a4e732a1904a68)
(cherry picked from commit e9694e67ab93ad74f7eae3152d88d95e8493e739)
(cherry picked from commit a9763edaf002c8009a2cca4115cb8b926f8cdc85)
(cherry picked from commit e2b550f4fba144f9637a212b56bfe30cac1adb3b)
(cherry picked from commit 2edac36701e8fa1ff67f87dccfa34cfc00ab66de)
[API] Forgejo API /api/forgejo/v1 (squash)
Update semver as v1.20 is entering release candidate mode
(cherry picked from commit 4995098ec3c6eee19a7ad7bc956b71c6e937c04c)
(cherry picked from commit 578ccfdd27d7a280050bdf61d497d07decf98f2f)
(cherry picked from commit 1bf6ac09520490f0a56b9b55d7836c2d8ea5d22c)
(cherry picked from commit 2fe16b2bfed62c0386d0bfe104f7dcc621d1c3be)
(cherry picked from commit 7cd9d027eec5a2b328d06a47f34545943560fe1b)
(cherry picked from commit eaed4be2ae88055a15dcc96564440c301a13ba8e)
(cherry picked from commit cc94f3115f844a0f16064e49e5eb719d33bc4441)
(cherry picked from commit d7a77e35ccfd2d0fc2ba98932296ab7354edd2db)
(cherry picked from commit cd8eb68ab7b3e2eaacf78d370c762f43cc19fd6a)
(cherry picked from commit 68487ac95f742837e7ff38df902834b6173cd9ab)
(cherry picked from commit 616dceb565456d6fac6f58b1c4de43e9d3254090)
(cherry picked from commit 545fe5975b47d2eab348a57b87c6fd4590f33442)
(cherry picked from commit c042cf8eda2dea805138bd64daa7fbe07865ed5a)
(cherry picked from commit ae5e5a7468aa66312055a26841f658574a9b0dd7)
(cherry picked from commit 8034ef5fa2648a127f8c84c572bec02a1ff6bb9f)
(cherry picked from commit aaf0293034468505449d33ab1483ae65b4175754)
(cherry picked from commit daafa8ce58e5e6077da585b13e5190856228a4a3)
(cherry picked from commit 7ca3681d3e2ed5ec1ae44364cba476d642e2b557)
(cherry picked from commit 39f72cba71ff3f9d2cbb05c88031b34933573a8c)
(cherry picked from commit 60a591713097384935ba0ac51a5cd4793f7544a8)
(cherry picked from commit 4853bd9e16bc8986ba8159349e93bc3093dc8ab9)
[API] Move forgejo api file (squash)
- Move the file to accommodate faa28b5a44
(cherry picked from commit bce89351d251bfa18c677b30bc7da80856d919fb)
(cherry picked from commit 11ae7f6e85395b287c6f4108c531aa1a81fd964c)
(cherry picked from commit 25e96cfcb28859406329090eb0c7990bea4e73eb)
(cherry picked from commit 6d8d19b39156a7f8b4db5022915590593df94f1f)
(cherry picked from commit 5afc5c454b7d70f95b83e6c3b4c9e2cb6e2d0ef5)
(cherry picked from commit 86d07b4c249211bdb77c0520f99f2c8e5d89b516)
(cherry picked from commit e54d869fdae44811faaa80f3757efbc93bf0bce4)
(cherry picked from commit ab31ef1bba3bc5188e0f3ce5e5fa33335877cf47)
(cherry picked from commit 511cbca2f3799646edf8eae00464b87f43ca280f)
(cherry picked from commit 333916fea874509063f9449f07d79e4cafbcf06f)
(cherry picked from commit 3802bcd7c9865b77151ef454c0bdc2ce32157a41)
(cherry picked from commit 5d0fa034f77388ed21735a22cf1a2a23562245c3)
(cherry picked from commit d15627aa0dfb4ffc2eb7ab0ce99b7c5b2bf06dcf)
(cherry picked from commit ba0b21b9305b6fecf23aeec213f1a95d96ce72fb)
(cherry picked from commit 39ade66aac7f8cccd980d1f435b92465a50be032)
Fixes#28660
Fixes an admin api bug related to `user.LoginSource`
Fixed `/user/emails` response not identical to GitHub api
This PR unifies the user update methods. The goal is to keep the logic
only at one place (having audit logs in mind). For example, do the
password checks only in one method not everywhere a password is updated.
After that PR is merged, the user creation should be next.
This change allows act_runner / actions_runner to use jwt tokens for
`ACTIONS_RUNTIME_TOKEN` that are compatible with
actions/upload-artifact@v4.
The official Artifact actions are now validating and extracting the jwt
claim scp to get the runid and jobid, the old artifact backend also
needs to accept the same token jwt.
---
Related to #28853
I'm not familar with the auth system, maybe you know how to improve this
I have tested
- the jwt token is a valid token for artifact uploading
- the jwt token can be parsed by actions/upload-artifact@v4 and passes
their scp claim validation
Next steps would be a new artifacts@v4 backend.
~~I'm linking the act_runner change soonish.~~
act_runner change to make the change effective and use jwt tokens
<https://gitea.com/gitea/act_runner/pulls/471>
In #28691, schedule plans will be deleted when a repo's actions unit is
disabled. But when the unit is enabled, the schedule plans won't be
created again.
This PR fixes the bug. The schedule plans will be created again when the
actions unit is re-enabled
## Purpose
This is a refactor toward building an abstraction over managing git
repositories.
Afterwards, it does not matter anymore if they are stored on the local
disk or somewhere remote.
## What this PR changes
We used `git.OpenRepository` everywhere previously.
Now, we should split them into two distinct functions:
Firstly, there are temporary repositories which do not change:
```go
git.OpenRepository(ctx, diskPath)
```
Gitea managed repositories having a record in the database in the
`repository` table are moved into the new package `gitrepo`:
```go
gitrepo.OpenRepository(ctx, repo_model.Repo)
```
Why is `repo_model.Repository` the second parameter instead of file
path?
Because then we can easily adapt our repository storage strategy.
The repositories can be stored locally, however, they could just as well
be stored on a remote server.
## Further changes in other PRs
- A Git Command wrapper on package `gitrepo` could be created. i.e.
`NewCommand(ctx, repo_model.Repository, commands...)`. `git.RunOpts{Dir:
repo.RepoPath()}`, the directory should be empty before invoking this
method and it can be filled in the function only. #28940
- Remove the `RepoPath()`/`WikiPath()` functions to reduce the
possibility of mistakes.
---------
Co-authored-by: delvh <dev.lh@web.de>
Currently, the `updateMirror` function which update the mirror interval
and enable prune properties is only executed by the `Edit` function. But
it is only triggered if `opts.MirrorInterval` is not null, even if
`opts.EnablePrune` is not null.
With this patch, it is now possible to update the enable_prune property
with a patch request without modifying the mirror_interval.
## Example request with httpie
### Currently:
**Does nothing**
```bash
http PATCH https://gitea.your-server/api/v1/repos/myOrg/myRepo "enable_prune:=false" -A bearer -a $gitea_token
```
**Updates both properties**
```bash
http PATCH https://gitea.your-server/api/v1/repos/myOrg/myRepo "enable_prune:=false" "mirror_interval=10m" -A bearer -a $gitea_token
```
### With the patch
**Updates enable_prune only**
```bash
http PATCH https://gitea.your-server/api/v1/repos/myOrg/myRepo "enable_prune:=false" -A bearer -a $gitea_token
```
Fix `Uploaded artifacts should be overwritten`
https://github.com/go-gitea/gitea/issues/28549
When upload different content to uploaded artifact, it checks that
content size is not match in db record with previous artifact size, then
the new artifact is refused.
Now if it finds uploading content size is not matching db record when
receiving chunks, it updates db records to follow the latest size value.
Sometimes you need to work on a feature which depends on another (unmerged) feature.
In this case, you may create a PR based on that feature instead of the main branch.
Currently, such PRs will be closed without the possibility to reopen in case the parent feature is merged and its branch is deleted.
Automatic target branch change make life a lot easier in such cases.
Github and Bitbucket behave in such way.
Example:
$PR_1$: main <- feature1
$PR_2$: feature1 <- feature2
Currently, merging $PR_1$ and deleting its branch leads to $PR_2$ being closed without the possibility to reopen.
This is both annoying and loses the review history when you open a new PR.
With this change, $PR_2$ will change its target branch to main ($PR_2$: main <- feature2) after $PR_1$ has been merged and its branch has been deleted.
This behavior is enabled by default but can be disabled.
For security reasons, this target branch change will not be executed when merging PRs targeting another repo.
Fixes#27062Fixes#18408
---------
Co-authored-by: Denys Konovalov <kontakt@denyskon.de>
Co-authored-by: delvh <dev.lh@web.de>
Fixes#27114.
* In Gitea 1.12 (#9532), a "dismiss stale approvals" branch protection
setting was introduced, for ignoring stale reviews when verifying the
approval count of a pull request.
* In Gitea 1.14 (#12674), the "dismiss review" feature was added.
* This caused confusion with users (#25858), as "dismiss" now means 2
different things.
* In Gitea 1.20 (#25882), the behavior of the "dismiss stale approvals"
branch protection was modified to actually dismiss the stale review.
For some users this new behavior of dismissing the stale reviews is not
desirable.
So this PR reintroduces the old behavior as a new "ignore stale
approvals" branch protection setting.
---------
Co-authored-by: delvh <dev.lh@web.de>
Fix#28157
This PR fix the possible bugs about actions schedule.
## The Changes
- 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.
Fix#27722Fix#27357Fix#25837
1. Fix the typo `BlockingByDependenciesNotPermitted`, which causes the
`not permitted message` not to show. The correct one is `Blocking` or
`BlockedBy`
2. Rewrite the perm check. The perm check uses a very tricky way to
avoid duplicate checks for a slice of issues, which is confusing. In
fact, it's also the reason causing the bug. It uses `lastRepoID` and
`lastPerm` to avoid duplicate checks, but forgets to assign the
`lastPerm` at the end of the code block. So I rewrote this to avoid this
trick.
3. It also reuses the `blocks` slice, which is even more confusing. So I
rewrote this too.
Introduce the new generic deletion methods
- `func DeleteByID[T any](ctx context.Context, id int64) (int64, error)`
- `func DeleteByIDs[T any](ctx context.Context, ids ...int64) error`
- `func Delete[T any](ctx context.Context, opts FindOptions) (int64,
error)`
So, we no longer need any specific deletion method and can just use
the generic ones instead.
Replacement of #28450Closes#28450
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
The CORS code has been unmaintained for long time, and the behavior is
not correct.
This PR tries to improve it. The key point is written as comment in
code. And add more tests.
Fix#28515Fix#27642Fix#17098
Related to https://github.com/go-gitea/gitea/issues/28279
When merging artifact chunks, it lists chunks from storage. When storage
is minio, chunk's path contains `MINIO_BASE_PATH` that makes merging
break.
<del>So trim the `MINIO_BASE_PATH` when handle chunks.</del>
Update the chunk file's basename to retain necessary information. It
ensures that the directory in the chunk's path remains unaffected.
Nowadays, cache will be used on almost everywhere of Gitea and it cannot
be disabled, otherwise some features will become unaviable.
Then I think we can just remove the option for cache enable. That means
cache cannot be disabled.
But of course, we can still use cache configuration to set how should
Gitea use the cache.
The 4 functions are duplicated, especially as interface methods. I think
we just need to keep `MustID` the only one and remove other 3.
```
MustID(b []byte) ObjectID
MustIDFromString(s string) ObjectID
NewID(b []byte) (ObjectID, error)
NewIDFromString(s string) (ObjectID, error)
```
Introduced the new interfrace method `ComputeHash` which will replace
the interface `HasherInterface`. Now we don't need to keep two
interfaces.
Reintroduced `git.NewIDFromString` and `git.MustIDFromString`. The new
function will detect the hash length to decide which objectformat of it.
If it's 40, then it's SHA1. If it's 64, then it's SHA256. This will be
right if the commitID is a full one. So the parameter should be always a
full commit id.
@AdamMajer Please review.
- Modify the `Password` field in `CreateUserOption` struct to remove the
`Required` tag
- Update the `v1_json.tmpl` template to include the `email` field and
remove the `password` field
---------
Signed-off-by: Bo-Yi Wu <appleboy.tw@gmail.com>
- Remove `ObjectFormatID`
- Remove function `ObjectFormatFromID`.
- Use `Sha1ObjectFormat` directly but not a pointer because it's an
empty struct.
- Store `ObjectFormatName` in `repository` struct
Refactor Hash interfaces and centralize hash function. This will allow
easier introduction of different hash function later on.
This forms the "no-op" part of the SHA256 enablement patch.
Recently Docker started to use the optional `POST /v2/token` endpoint
which should respond with a `404 Not Found` status code instead of the
current `405 Method Not Allowed`.
> Note: Not all token servers implement oauth2. If the request to the
endpoint returns 404 using the HTTP POST method, refer to Token
Documentation for using the HTTP GET method supported by all token
servers.
## Changes
- Add deprecation warning to `Token` and `AccessToken` authentication
methods in swagger.
- Add deprecation warning header to API response. Example:
```
HTTP/1.1 200 OK
...
Warning: token and access_token API authentication is deprecated
...
```
- Add setting `DISABLE_QUERY_AUTH_TOKEN` to reject query string auth
tokens entirely. Default is `false`
## Next steps
- `DISABLE_QUERY_AUTH_TOKEN` should be true in a subsequent release and
the methods should be removed in swagger
- `DISABLE_QUERY_AUTH_TOKEN` should be removed and the implementation of
the auth methods in question should be removed
## Open questions
- Should there be further changes to the swagger documentation?
Deprecation is not yet supported for security definitions (coming in
[OpenAPI Spec version
3.2.0](https://github.com/OAI/OpenAPI-Specification/issues/2506))
- Should the API router logger sanitize urls that use `token` or
`access_token`? (This is obviously an insufficient solution on its own)
---------
Co-authored-by: delvh <dev.lh@web.de>
Fix#28056
This PR will check whether the repo has zero branch when pushing a
branch. If that, it means this repository hasn't been synced.
The reason caused that is after user upgrade from v1.20 -> v1.21, he
just push branches without visit the repository user interface. Because
all repositories routers will check whether a branches sync is necessary
but push has not such check.
For every repository, it has two states, synced or not synced. If there
is zero branch for a repository, then it will be assumed as non-sync
state. Otherwise, it's synced state. So if we think it's synced, we just
need to update branch/insert new branch. Otherwise do a full sync. So
that, for every push, there will be almost no extra load added. It's
high performance than yours.
For the implementation, we in fact will try to update the branch first,
if updated success with affect records > 0, then all are done. Because
that means the branch has been in the database. If no record is
affected, that means the branch does not exist in database. So there are
two possibilities. One is this is a new branch, then we just need to
insert the record. Another is the branches haven't been synced, then we
need to sync all the branches into database.
Earl Warren
