When searching for users, page the results by default, and respect the
default paging limits.
This makes queries like '/api/v1/users/search?limit=1' actually work.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
If `[email.incoming].USE_TLS` is set, but the port isn't, infer the
default from `.USE_TLS`: set the port to 993 if using tls, and to 143
otherwise. Explicitly setting a port overrides this.
Fixes#3357.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
The keys for setting the username and password for incoming and outgoing
mail are inconsisent: one uses `USERNAME` and `PASSWORD`, the other uses
`USER` and `PASSWD`.
To make things simpler, allow both to be configured by either, thus,
`[mailer].USERNAME` and `[mailer.PASSWORD]` will be aliases for `.USER`
and `.PASSWD`, and similarly, `[email.incoming].USER` and
`[email.incoming].PASSWD` will be aliases for `.USERNAME` and
`.PASSWORD`.
Fixes#3355.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Fixes: https://github.com/go-gitea/gitea/issues/30384
On repo settings page, there id `repo_name` was used 5 times on the same
page, some in modal and such. I think we are better off just
auto-generating these IDs in the future so that labels link up with
their form element.
Ideally this id generation would be done in backend in a subtemplate,
but seeing that we already have similar JS patches for checkboxes, I
took the easy path for now.
I also checked that these `#repo_name` were not in use in JS and the
only case where this id appears in JS is on the migration page where
it's still there.
---------
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit d4ec6b3d16496ce3b479d5a08f79823122dc2b7b)
Conflicts:
- templates/repo/settings/options.tmpl
Conflict resolved by manually removing all `id` and `for`
attributes from elements that had `repo_name` as their id.
Fixes#28255
The new query uses the id field to sort by "newer". This most not be
correct (usually it is) but it's faster (see #28255).
If someone has a better idea, please propose changes.
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit b06aac40e6552b0ce1f7b8a92c977fcc27566f68)
Follow https://github.com/go-gitea/gitea/pull/30357
When user push to default branch, the schedule trigger user will be the
user.
When disable then enable action units in settings, the schedule trigger
user will be action user.
When repo is a mirror, the schedule trigger user will be action user. (
before it will return error, fixed by #30357)
As scheduled job is a cron, the trigger user should be action user from
Gitea, not a real user.
---------
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit cb6814adad4dc81a683b50826a211ce7bce731d7)
Conflicts:
- services/actions/notifier_helper.go
Conflict resolved by keeping Forgejo's version of the line.
Related to #30375.
It doesn't make sense to import `modules/web/middleware` and
`modules/setting` in `modules/web/session` since the last one is more
low-level.
And it looks like a workaround to call `DeleteLegacySiteCookie` in
`RegenerateSession`, so maybe we could reverse the importing by
registering hook functions.
(cherry picked from commit 61457cdf6b49225ae831fd9fb084deadd8bdb0fb)
Files in root were not linted, add them. No new violations.
(cherry picked from commit 354705450a410329d253023d2c66ef6d68ecc046)
Conflicts:
- CHANGELOG.md
Gitea specific, removed.
- Makefile
Adjusted SPELLCHECK_FILES: we don't need to filter the
CHANGELOG.md out. The conflict itself was resolved by manually
applying the change.
Fixes https://github.com/go-gitea/gitea/issues/28114 and behaviour
matches vscode on desktop as well.
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 49b80f8ac1cf9f0b56da0c73d0f34ef030f4c447)
Add some logic in `convert.ToBranchProtection` to return only the names
associated with readAccess instead of returning all names. This will
ensure consistency in behavior between the frontend and backend.
Fixes: #27694
---------
Co-authored-by: techknowlogick <techknowlogick@gitea.com>
Co-authored-by: wenzhuo.zhang <wenzhuo.zhang@geely.com>
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 02e183bf3fa502b7cef76e8dcdbf01b85ce641f0)
Fixes: https://github.com/go-gitea/gitea/issues/30512
I think this does mean those tools would run on a potential `vendor`
directory, but I'm not sure we really support vendoring of dependencies
anymore.
`release` has a `vendor` prerequisite so likely the source tarballs
contain vendor files?
(cherry picked from commit 8e12ef911a1d10dedb03e3127c42ca76f9850aca)
Conflicts:
- Makefile
Manually adjusted the changes.
Using the API, a user's _source_id_ can be set in the _CreateUserOption_
model, but the field is not returned in the _User_ model.
This PR updates the _User_ model to include the field _source_id_ (The
ID of the Authentication Source).
(cherry picked from commit 58b204b813cd3a97db904d889d552e64a7e398ff)
- Add new `Compare` struct to represent comparison between two commits
- Introduce new API endpoint `/compare/*` to get commit comparison
information
- Create new file `repo_compare.go` with the `Compare` struct definition
- Add new file `compare.go` in `routers/api/v1/repo` to handle
comparison logic
- Add new file `compare.go` in `routers/common` to define `CompareInfo`
struct
- Refactor `ParseCompareInfo` function to use `common.CompareInfo`
struct
- Update Swagger documentation to include the new API endpoint for
commit comparison
- Remove duplicate `CompareInfo` struct from
`routers/web/repo/compare.go`
- Adjust base path in Swagger template to be relative (`/api/v1`)
GitHub API
https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28#compare-two-commits
---------
Signed-off-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
(cherry picked from commit c70e442ce4b99e2a1f1bf216afcfa1ad78d1925a)
Conflicts:
- routers/api/v1/swagger/repo.go
Conflict resolved by manually adding the lines from the Gitea
PR.
Small tweak here to prevent this and likely other events from
overflowing in the timeline:
<img width="895" alt="Screenshot 2024-04-14 at 22 53 17"
src="https://github.com/go-gitea/gitea/assets/115237/001b4f6b-f649-44ff-b2f0-c8e0dedeb384">
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 1508a85f6235814271ea927d651bcbcd8c9f5f18)
So it happened to me multiple times that air leaves zombie processes
after termination. I think ultimately it's some kind of bug in air, but
we can work around.
The change in the delay is unrelated to the zombie processes but seems
to help a bit with duplicate changes resulting in duplicate `make
generate` as seen here:
<img width="424" alt="Screenshot 2024-04-14 at 17 05 47"
src="https://github.com/go-gitea/gitea/assets/115237/6dd1d787-6be3-4fb2-8b0b-cd711c281793">
---------
Co-authored-by: delvh <dev.lh@web.de>
(cherry picked from commit 994920c677b04a720726d982e4d6212664b82a43)
