Backport #20158
Unforunately the previous PR #20035 created indices that were not helpful
for SQLite. This PR adjusts these after testing using the try.gitea.io db.
Fix #20129
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Check if project has the same repository id with issue when assign project to issue
* Check if issue's repository id match project's repository id
* Add more permission checking
* Remove invalid argument
* Fix errors
* Add generic check
* Remove duplicated check
* Return error + add check for new issues
* Apply suggestions from code review
Co-authored-by: Gusted <williamzijl7@hotmail.com>
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
Co-authored-by: 6543 <6543@obermui.de>
- Backport #20142
- Firefox on Windows will unconditionally show scrollbars when you specify `overflow: scroll`. This is bad behavior, as you don't always need the scrollbar. Changing the scroll value to auto fixes this issue and only shows the scrollbar when necessary.
- Resolves #20139
Backport #20127
Store the file uuid(which is returned by Gitea in the upload file response) onto the file object, so it can be used for the remove feature to specify this file.
Fix #20115
The code introduced by #18185 gets the error from response after it was processed by goth.
That is incorrect, as goth (and golang.org/x/oauth) doesn't really care about the error, and it sends a token request with an empty authorization code to the server anyway, which always results in a `oauth2: cannot fetch token: 400 Bad Request` error from goth.
It means that unless the "state" parameter is omitted from the error response (which is required to be present, according to [RFC 6749, Section 4.1.2.1](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2.1)) or the page is reloaded (makes the session invalid), a 500 Internal Server Error page will be displayed.
This fixes it by handling the error before the request is passed to goth.
* Disable federation by default (#20045)
- Backport #20045
- A Gitea instance should choose whetever they want to federate(as once it has more features also brings extra costs/moderation/unexpected behavior) with other AP/ForgeFed software.
* Fix tests
There appears to be a strange bug whereby the comment_id index can sometimes be missed
or missing from the action table despite the sync2 that should create it in the earlier
part of this migration. However, looking through the code for Sync2 there is no need
for this pre-code to exist and Sync2 should drop/create the indices as necessary.
I think therefore we should simplify the migration to simply be Sync2.
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: 6543 <6543@obermui.de>
Fixes #19090
If the user-agent starts with git and user must change password but
hasn't return a 401 with the message.
It must be a 401, git doesn't seem to show the contents of the error message
when we return a 403
Co-authored-by: 6543 <6543@obermui.de>
Backport #20032
In DeleteIssue the PR git head reference should be `/refs/pull/xxx/head` not `/refs/pull/xxx`
Fix #19655
Signed-off-by: a1012112796 <1012112796@qq.com>
fgprof is a sampling Go profiler that allows you to analyze On-CPU as
well as Off-CPU (e.g. I/O) time together.
Go's builtin sampling CPU profiler can only show On-CPU time, but it's
better than fgprof at that. Go also includes tracing profilers that can
analyze I/O, but they can't be combined with the CPU profiler.
fgprof is designed for analyzing applications with mixed I/O and CPU
workloads. This kind of profiling is also known as wall-clock profiling.
Whilst fgprof can cause significant STW latencies in applications with a
lot of goroutines (> 1-10k), these latencies only occur if the profile
is requested - it doesn't cause a delay by simply being available.
The fgprof profile is mounted on
`http://localhost:6060/debug/fgprof?seconds=3`
Signed-off-by: Andrew Thornton <art27@cantab.net>
It appears possible that stopwatches can become orphaned or have been orphaned in
the past.
This PR adds Orphan checks for Stopwatches.
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Empty log queue on flush and close
It is possible for log events to remain in the buffer off the multichannelledlog
and thus not be logged despite close or flush.
This PR simply adds a function to empty the queue before closing or flushing.
(Except when the logger is paused.)
Reference #19982
Signed-off-by: Andrew Thornton <art27@cantab.net>
* and do similar for ChannelledLog
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
If there are dangling stopwatches with missing issues there will be repeated
logging of Unable to APIFormat stopwatches. These are unhelpful and instead
we should only log if the error is not an issue not exist error.
And we should also prevent an error on missing issue in GetActiveStopwatch too
Signed-off-by: Andrew Thornton <art27@cantab.net>
gitea doctor --run check-db-consistency is currently broken due to an incorrect
and old use of Count() with a string.
Signed-off-by: Andrew Thornton <art27@cantab.net>
When migrating git repositories we should ensure that the commit-graph is written.
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: delvh <dev.lh@web.de>
Add fetch.writeCommitGraph to gitconfig to ensure that a commit-graph will be written
on git fetch calls.
Signed-off-by: Andrew Thornton <art27@cantab.net>
Allow git push to work when networked file systems with mixed
ownership are used with Gitea docker images >= 1.16.6 or Gitea
binaries running alongside git versions published after 04/2022.
There are circumstances independent of Gitea (networked file systems
with various permission systems) by which the git repositories managed
by Gitea may have mixed owners. It is not a behavior that Gitea have
control over nor is it a problem as long as the permissions for Gitea to
operate are correct. Gitea instances have been operating under these
conditions for a number of years.
It is detected as a potential security risk ( see
GHSA-vw2c-22j4-2fh2
) by the most recent git versions. However, Gitea always runs git
commands with a current directory matching the repository on
which it operates. That makes Gitea immune from this security problem
and it is safe to ignore the mixed owner permission check.
This gitconfig modification is done on a file dedicated to the user
exclusively used by Gitea.
Fixes: #19455
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: zeripath <art27@cantab.net>
* clean git support for ver < 2.0
* fine tune tests for markup (which requires git module)
* remove unnecessary comments
* try to fix tests
* try test again
* use const for GitVersionRequired instead of var
* try to fix integration test
* Refactor CheckAttributeReader to make a *git.Repository version
* update document for commit signing with Gitea's internal gitconfig
* update document for commit signing with Gitea's internal gitconfig
Co-authored-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
- Fomantic tries to prevent overflowing on the `y/x`-as by default on
stackable menu's on mobile screens. We already solve this issue by
forcing overflow on x as and hide it on y as(due to some issues with
other menu's), since https://github.com/go-gitea/gitea/pull/19486.
- However this edge case does require a y-overflow to show the dropdown,
because you cannot easily adjust this with CSS, once you're fiddling
with overflow's (https://stackoverflow.com/a/6433475). However
interesting behavior is noted
https://css-tricks.com/popping-hidden-overflow/ when you remove the
position: relative, it will suddenly work again. Well because this is
the only solution without redesigning dropdowns, I think we can live
with the side-effect of the dropdown items being full-width instead
"relative" width to their parent.
- Resolves #19976
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
- We don't need to buffer the logger with a thousand capacity. It's not
a high-throughput logger, this also caused issue whereby the logger
can't keep up with repeated messages being send(somehow they are lost in
the queue?).
- Resolves #19969
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
