- Use TXT records in order to determine the latest available version.
- This addresses a valid privacy issue, as with HTTP requests the server
can keep track(estimated) of how many instances are using Forgejo, with
DNS that's basically not possible as the server will never receive any
data, as the only ones receiving data are DNS resolvers.
(cherry picked from commit 0baefb546a)
(cherry picked from commit e8ee41880b)
(cherry picked from commit 7eca4f3bf1)
(cherry picked from commit 6dde3992dc)
(cherry picked from commit fb3a37fbfc)
(cherry picked from commit 8304af1e9d)
(cherry picked from commit 0543a7d12a)
(cherry picked from commit c3a22933b7)
(cherry picked from commit e243707694)
(cherry picked from commit 7eb6d1bcf7)
(cherry picked from commit 1d7b9535cd)
(cherry picked from commit 05920dce67)
(cherry picked from commit f173f27d7c)
(cherry picked from commit 90e1c9340e)
(cherry picked from commit de68610ea7)
(cherry picked from commit 8d5757ea04)
(cherry picked from commit c7a7fff316)
(cherry picked from commit 39ac8b8fc1)
(cherry picked from commit 9889203301)
[PRIVACY]: Adjust update checker description
- Resolves#323
- Adjust the description of the update check function on the
installation page to describe the privacy method instead of the HTTP
method by checking gitea.io
(cherry picked from commit 61eae5b105)
(cherry picked from commit 091def20a1)
(cherry picked from commit d5d11bf45a)
(cherry picked from commit 71863d4707)
(cherry picked from commit 11ece4aab1)
(cherry picked from commit afdd7e714f)
(cherry picked from commit 39170e2f1d)
(cherry picked from commit 4b3a52aab8)
(cherry picked from commit 9d763c5fc8)
(cherry picked from commit 638db15482)
(cherry picked from commit a52bfdd8e7)
(cherry picked from commit dc93d00e85)
(cherry picked from commit 0bc4b3508c)
(cherry picked from commit 3f760d85a4)
(cherry picked from commit ecc2716785)
(cherry picked from commit 6334d5677e)
Conflicts:
modules/updatechecker/update_checker.go
UpdateRemoteVersion now has a context argument. However, in
the updated code from Gitea the context comes from the HTTP
request and does not actually provide any useful context.
Replace that with context.Background()
(cherry picked from commit ca2200767e)
(cherry picked from commit f46feca224)
(cherry picked from commit a800a66ca8)
(cherry picked from commit 21f017454e)
(cherry picked from commit 762d18e09a)
(cherry picked from commit 6d28e120c1)
(cherry picked from commit 4fcd7e7cbf)
(cherry picked from commit 9516285112)
(cherry picked from commit 0dd752a262)
(cherry picked from commit b1f1af7fe0)
(cherry picked from commit 71937deaa5)
(cherry picked from commit 93e41a7823)
(cherry picked from commit f497ed30cf)
[GITEA] Fix cancelled migration deletion modal
- https://codeberg.org/forgejo/forgejo/pulls/1473 made that dangerous
actions such as deletion also would need to type in the owner's name.
This was apparently not reflected to the deletion modal for migrations
that failed or were cancelled.
(cherry picked from commit c38dbd6f88)
(cherry picked from commit 7c07592d01)
(cherry picked from commit 78637af2b6)
[SHARED] make confirmation clearer for dangerous actions
- Currently the confirmation for dangerous actions such as transferring
the repository or deleting it only requires the user to ~~copy paste~~
type the repository name.
- This can be problematic when the user has a fork or another repository
with the same name as an organization's repository, and the confirmation
doesn't make clear that it could be deleting the wrong repository. While
it's mentioned in the dialog, it's better to be on the safe side and
also add the owner's name to be an element that has to be typed for
these dangerous actions.
- Added integration tests.
(cherry picked from commit bf679b24dd)
(cherry picked from commit 1963085dd9)
(cherry picked from commit fb94095d19)
(cherry picked from commit e1d1e46afe)
(cherry picked from commit 93993029e4)
(cherry picked from commit df3b058179)
(cherry picked from commit 8ccc6b9cba)
(cherry picked from commit 9fbe28fca3)
(cherry picked from commit 4ef2be6dc7)
https://codeberg.org/forgejo/forgejo/pulls/1873
Moved test from repo_test.go to forgejo_confirmation_repo_test.go to
avoid conflicts.
(cherry picked from commit 83cae67aa3)
(cherry picked from commit 447009ff56)
(cherry picked from commit 72c0a6150a)
(cherry picked from commit 8ee9c070b9)
(cherry picked from commit 89aba06403)
(cherry picked from commit 798407599f)
(cherry picked from commit 41c9a2606b)
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 c524d33402)
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 f061caa655)
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 ea36cf80f5)
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 96150971ca)
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 4926a5d7a2)
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 76c8faecdc)
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 cf787ad7fd)
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 1e4ff424d3)
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 da932152f1)
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 1f6a42808d)
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 8f22ea182e)
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 961fd13c55)
(cherry picked from commit d52f4eea44)
(cherry picked from commit 3540ea2a43)
Conflicts:
services/issue/issue.go
https://codeberg.org/forgejo/forgejo/pulls/1415
(cherry picked from commit 56720ade00)
Conflicts:
routers/api/v1/repo/issue_label.go
https://codeberg.org/forgejo/forgejo/pulls/1462
(cherry picked from commit 47c78927d6)
(cherry picked from commit 2030f3b965)
(cherry picked from commit f02aeb7698)
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 d072525b35)
(cherry picked from commit 8424d0ab3d)
(cherry picked from commit 5cc62caec7)
(cherry picked from commit d6300d5dcd)
[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 ac4f727f63)
(cherry picked from commit 5110476ee9)
(cherry picked from commit 77ba6be1da)
(cherry picked from commit 9c8337b5c4)
(cherry picked from commit 1d689eb686)
(cherry picked from commit 511c519c87)
(cherry picked from commit 2f0b4a8f61)
(cherry picked from commit fdd4da111c)
[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 c5139a75b9)
(cherry picked from commit c7b572c35d)
(cherry picked from commit aec7503ff6)
(cherry picked from commit 87c65f2a49)
(cherry picked from commit 20b5669269)
(cherry picked from commit 1574643a6a)
Update semantic version according to specification
(cherry picked from commit 22510f4130)
Mise à jour de 'Makefile'
(cherry picked from commit c3d85d8409)
(cherry picked from commit 5ea2309851)
(cherry picked from commit ec5217b9d1)
(cherry picked from commit 14f08e364b)
(cherry picked from commit b4465c67b8)
[API] [SEMVER] replace number with version
(cherry picked from commit fba48e6497)
(cherry picked from commit 532ec5d878)
[API] [SEMVER] [v1.20] less is replaced by css
(cherry picked from commit 01ca3a4f42)
(cherry picked from commit 1d928c3ab2)
(cherry picked from commit a39dc804cd)
Conflicts:
webpack.config.js
(cherry picked from commit adc68578b3)
(cherry picked from commit 9b8d98475f)
(cherry picked from commit 2516103974)
(cherry picked from commit 18e6287963)
(cherry picked from commit e9694e67ab)
(cherry picked from commit a9763edaf0)
(cherry picked from commit e2b550f4fb)
(cherry picked from commit 2edac36701)
[API] Forgejo API /api/forgejo/v1 (squash)
Update semver as v1.20 is entering release candidate mode
(cherry picked from commit 4995098ec3)
(cherry picked from commit 578ccfdd27)
(cherry picked from commit 1bf6ac0952)
(cherry picked from commit 2fe16b2bfe)
(cherry picked from commit 7cd9d027ee)
(cherry picked from commit eaed4be2ae)
(cherry picked from commit cc94f3115f)
(cherry picked from commit d7a77e35cc)
(cherry picked from commit cd8eb68ab7)
(cherry picked from commit 68487ac95f)
(cherry picked from commit 616dceb565)
(cherry picked from commit 545fe5975b)
(cherry picked from commit c042cf8eda)
(cherry picked from commit ae5e5a7468)
(cherry picked from commit 8034ef5fa2)
(cherry picked from commit aaf0293034)
(cherry picked from commit daafa8ce58)
(cherry picked from commit 7ca3681d3e)
(cherry picked from commit 39f72cba71)
(cherry picked from commit 60a5917130)
(cherry picked from commit 4853bd9e16)
[API] Move forgejo api file (squash)
- Move the file to accommodate faa28b5a44
(cherry picked from commit bce89351d2)
(cherry picked from commit 11ae7f6e85)
(cherry picked from commit 25e96cfcb2)
(cherry picked from commit 6d8d19b391)
(cherry picked from commit 5afc5c454b)
(cherry picked from commit 86d07b4c24)
(cherry picked from commit e54d869fda)
(cherry picked from commit ab31ef1bba)
(cherry picked from commit 511cbca2f3)
(cherry picked from commit 333916fea8)
(cherry picked from commit 3802bcd7c9)
(cherry picked from commit 5d0fa034f7)
(cherry picked from commit d15627aa0d)
- Use htmx to perform the button request
- `hx-headers='{"x-csrf-token": "{{.CsrfToken}}"}'` to authenticate (we
should probably learn to reuse this)
- `hx-post="{{.ContextUser.HomeLink}}?action=follow"` to send a POST
request to follow the user
- `hx-target="#profile-avatar-card"` to target the card div for
replacement
- `hx-swap="outerHTML"` to replace the card (as opposed to its inner
content) with the new card that shows the new follower count and button
color
- Change the backend response to return a `<div>` tag (the card) instead
of a redirect to the user page
# Before
# After
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
- Refactor the form around the subscribe button into its own template
- Use htmx to perform the form submission
- `hx-boost="true"` to prevent the default form submission behavior of a
full page load
- `hx-sync="this:replace"` to replace the current request (in case the
button is clicked again before the response is returned)
- `hx-target="this"` to replace the form tag with the new form tag
- `hx-push-url="false"` to disable a change to the URL
- `hx-swap="show:no-scroll"` to preserve the scroll position
- Change the backend response to return a `<form>` tag instead of a
redirect to the issue page
- Include `htmx.org` in javascript imports
This change introduces htmx with the hope we could use it to make Gitea
more reactive while keeping our "HTML rendered on the server" approach.
# Before
# After
---------
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
As more and more options can be set for creating the repository, I don't
think we should put all of them into the creation web page which will
make things look complicated and confusing.
And I think we need some rules about how to decide which should/should
not be put in creating a repository page. One rule I can imagine is if
this option can be changed later and it's not a MUST on the creation,
then it can be removed on the page. So I found trust model is the first
one.
This PR removed the trust model selections on creating a repository web
page and kept others as before.
This is also a preparation for #23894 which will add a choice about SHA1
or SHA256 that cannot be changed once the repository created.
By clicking the currently active "Open" or "Closed" filter button in the
issue list, the user can toggle that filter off in order to see all
issues regardless of state. The URL "state" parameter will be set to
"all" and the "Open"/"Closed" button will not show as active.
Fixes#26548
This PR refactors the rendering of markup links. The old code uses
`strings.Replace` to change some urls while the new code uses more
context to decide which link should be generated.
The added tests should ensure the same output for the old and new
behaviour (besides the bug).
We may need to refactor the rendering a bit more to make it clear how
the different helper methods render the input string. There are lots of
options (resolve links / images / mentions / git hashes / emojis / ...)
but you don't really know what helper uses which options. For example,
we currently support images in the user description which should not be
allowed I think:
<details>
<summary>Profile</summary>
https://try.gitea.io/KN4CK3R
</details>
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
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>
When JavaScript is not loaded, fall back to displaying reaction tooltips
with the default browser `title` attribute. An element with a present
but empty `data-tooltip-content` will use the `title` attribute for its
tippy.js tooltip content, so when JavaScript is enabled, this functions
the same as the current behavior.
Mainly for MySQL/MSSQL.
It is important for Gitea to use case-sensitive database charset
collation. If the database is using a case-insensitive collation, Gitea
will show startup error/warning messages, and show the errors/warnings
on the admin panel's Self-Check page.
Make `gitea doctor convert` work for MySQL to convert the collations of
database & tables & columns.
* Fix#28131
## ⚠️ BREAKING ⚠️
It is not quite breaking, but it's highly recommended to convert the
database&table&column to a consistent and case-sensitive collation.
In #26851, it assumed that `Commit` always exists when
`PageIsDiff==true`.
But for a 404 page, the `Commit` doesn't exist, so the following code
would cause panic because nil value can't be passed as string parameter
to `IsMultilineCommitMessage(string)` (or the StringUtils.Cut in later
PRs)
According to [Debian
docs](https://wiki.debian.org/DebianRepository/UseThirdParty):
> The certificate MUST NOT be placed in /etc/apt/trusted.gpg.d or loaded
by apt-key add.
> ...
> If future updates to the certificate will be managed by an apt/dpkg
package as recommended below, then it SHOULD be downloaded into
/usr/share/keyrings using the same filename that will be provided by the
package. If it will be managed locally , it SHOULD be downloaded into
/etc/apt/keyrings instead.
> ...
> A sources.list entry SHOULD have the signed-by option set.
There is an accessibility issue in the interface when attempting to
delete a repository. When I click on "Delete repository," a dialog box
appears, requiring confirmation to proceed with the repository deletion.
However, when I press the "Repo name" label, the wrong input field gains
focus. The focused field is located behind the dialog and is intended
for renaming the repository.
- 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>
Resolves https://github.com/go-gitea/gitea/issues/28451.
This change follows the recommendation by wxiaoguang to remove the
"Disable Minimum Key Size Check" from the "Service Configuration"
section of the UI, because this option belongs to the "SSH
Configuration" section of the administration menu and already has a
functioning indicator in that section of the UI.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
## 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>
