Hello there,
Cargo Index over HTTP is now prefered over git for package updates: we
should not force users who do not need the GIT repo to have the repo
created/updated on each publish (it can still be created in the packages
settings).
The current behavior when publishing is to check if the repo exist and
create it on the fly if not, then update it's content.
Cargo HTTP Index does not rely on the repo itself so this will be
useless for everyone not using the git protocol for cargo registry.
This PR only disable the creation on the fly of the repo when publishing
a crate.
This is linked to #26844 (error 500 when trying to publish a crate if
user is missing write access to the repo) because it's now optional.
---------
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
- The label HTML contained a quote that wasn't being closed.
Refs: https://codeberg.org/forgejo/forgejo/pulls/1651
(cherry picked from commit e2bc2c9a1fff482c49dbeb3a51e4e1c698bf506c)
Co-authored-by: Gusted <postmaster@gusted.xyz>
When hitting the `enter` key to create a new project column, the request
is sent twice because the `submit` event and `key up` event are both
triggered.
Probably a better solution is to rewrite these parts of the code to
avoid using native jQuery but reuse the `form-fetch-action` class. But
it's beyond my ability.
Per the discussion on #22054, the flow for adding a new team member to
an org is not intuitive for new Gitea users.
The ideal solution would be to add a new button on the Org > Members
index view (see the screenshot mockup in the issue description).
However, this would require a refactor of the UX for the flow. The
current flow has an implicit context of which team within the org the
new member is being added to ('Owners' by default). From the Members
index, there is no implicit context; the flow would have to add a picker
for which team the new member should be added to.
So, as a stopgap, this change simply adds a button to the Teams index
page that performs the same action as clicking on the title of the team
(a behavior that is currently too obscure as indicated in the comments
on the issue). This should reduce support burden and serve as a decent
temporary measure until the Add Member flow is refactored.
---------
Co-authored-by: tomholford <tomholford@users.noreply.github.com>
1. remove unused function `MoveIssueAcrossProjectBoards`
2. extract the project board condition into a function
3. use db.NoCondition instead of -1. (BTW, the usage of db.NoCondition
is too confusing. Is there any way to avoid that?)
4. remove the unnecessary comment since the ctx refactor is completed.
5. Change `b.ID != 0` to `b.ID > 0`. It's more intuitive but I think
they're the same since board ID can't be negative.
If you set a checkbox as required in a issue form at the moment, the
checkbox is checked and read only, what does not make much sense. With
this PR, the Checkbox actually needs to be checked. The label supports
now also Markdown. This matches GitHub's behaviour.
And yes, I know the CSS is a ugly workaround. It looks like the given
CSS code is part Fomantic and I don't know how to change that. The
Maintainers are free to change that.
1. Do not show temporary tooltips that are triggered from within
dropdowns. Previously this resulted in the tooltip being stuck to
top-left of the page like seen on issue comment URL copy. I could not
figure out any tippy options that prevent this, so I think it's better
to just not show it.
1. Refactor `initGlobalCopyToClipboardListener` so that it does not run
a often useless `document.querySelector` on every click, make
`data-clipboard-text-type` work with `data-clipboard-target`. No use in
current code base but still good to have. Finally some minor code
cleanup in the function.
Point 1 is for this copy button:
<img width="229" alt="image"
src="https://github.com/go-gitea/gitea/assets/115237/81f34746-8ea5-43d9-8c6f-f6f417a9e4ad">
---------
Co-authored-by: Giteabot <teabot@gitea.io>
When `webhook.PROXY_URL` has been set, the old code will check if the
proxy host is in `ALLOWED_HOST_LIST` or reject requests through the
proxy. It requires users to add the proxy host to `ALLOWED_HOST_LIST`.
However, it actually allows all requests to any port on the host, when
the proxy host is probably an internal address.
But things may be even worse. `ALLOWED_HOST_LIST` doesn't really work
when requests are sent to the allowed proxy, and the proxy could forward
them to any hosts.
This PR fixes it by:
- If the proxy has been set, always allow connectioins to the host and
port.
- Check `ALLOWED_HOST_LIST` before forwarding.
silverwind
merlleu
wxiaoguang
Earl Warren
Nanguan Lin
tomholford
Denys Konovalov
HoshinoRei
GiteaBot
6543
MrDevil
delvh
6543
JakobDev
MiloCubed
techknowlogick
SandeshPyakurel
sebastian-sauer
Jason Song
Lunny Xiao
KN4CK3R
yp05327
puni9869
Yevhen Pavlov
Sandro Santilli