This implements "repository flags", a way for instance administrators to
assign custom flags to repositories. The idea is that custom templates
can look at these flags, and display banners based on them, Forgejo does
not provide anything built on top of it, just the foundation. The
feature is optional, and disabled by default. To enable it, set
`[repository].ENABLE_FLAGS = true`.
On the UI side, instance administrators will see a new "Manage flags"
tab on repositories, and a list of enabled tags (if any) on the
repository home page. The "Manage flags" page allows them to remove
existing flags, or add any new ones that are listed in
`[repository].SETTABLE_FLAGS`.
The model does not enforce that only the `SETTABLE_FLAGS` are present.
If the setting is changed, old flags may remain present in the database,
and anything that uses them, will still work. The repository flag
management page will allow an instance administrator to remove them, but
not set them, once removed.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit ba735ce222)
(cherry picked from commit f09f6e029b)
Files can have an RSS feed, but those only make sense when taken in the
context of a branch. There is no history to make a feed of on a tag or a
commit: they're static. Forgejo does not provide a feed for them for
this reason.
However, the file view on the web UI was offering a link to these
non-existent feeds. With this patch, it does that no longer, and only
provides a link when viewing the file in the context of a branch.
Fixes#2102.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 4b48d21ea7)
(cherry picked from commit 70cb266760)
Adds `[repository].DOWNLOAD_OR_CLONE_METHODS` (defaulting to
"download-zip,download-targz,download-bundle,vscode-clone"), which lets
an instance administrator override the additional clone methods
displayed on the repository home view.
This is purely display-only, the clone methods not listed here are still
available, unless disabled elsewhere. They're just not displayed.
Fixes#710.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 2aadcf4946)
(cherry picked from commit 42ac34fbf9)
(cherry picked from commit bd231b0245)
(cherry picked from commit 3d3366dbbe)
This is largely based on gitea#6312 by @ashimokawa, with updates and
fixes by myself, and incorporates the review feedback given in that pull
request, and more.
What this patch does is add a new "default_permissions" column to the
`repo_units` table (defaulting to read permission), adjusts the
permission checking code to take this into consideration, and then
exposes a setting that lets a repo administrator enable any user on a
Forgejo instance to edit the repo's wiki (effectively giving the wiki
unit of the repo "write" permissions by default).
By default, wikis will remain restricted to collaborators, but with the
new setting exposed, they can be turned into globally editable wikis.
FixesCodeberg/Community#28.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 4b74439922)
(cherry picked from commit 337cf62c10)
(cherry picked from commit b6786fdb32)
(cherry picked from commit a5d2829a10)
[GITEA] Optionally allow anyone to edit Wikis (squash) AddTokenAuth
(cherry picked from commit fed50cf72e)
- Add a dropdown to the web interface for changing files to select which
Email should be used for the commit. It only shows (and verifies) that a
activated mail can be used, while this isn't necessary, it's better to
have this already in place.
- Added integration testing.
- Resolves https://codeberg.org/forgejo/forgejo/issues/281
(cherry picked from commit 564e701f40)
(cherry picked from commit de8f2e03cc)
(cherry picked from commit 0182cff12e)
(cherry picked from commit 9c74254d46)
(cherry picked from commit 2f0b68f821)
(cherry picked from commit 079b995d49)
(cherry picked from commit 6952ea6ee3)
(cherry picked from commit 6c7d5a5d14)
- Make it consistent with the other modals of the dangerous actions.
(cherry picked from commit 576d7ec759)
(cherry picked from commit 8b1225f974)
(cherry picked from commit c2c47972ee)
(cherry picked from commit eec301806b)
(cherry picked from commit 6b5e728f0a)
(cherry picked from commit 3681691e65)
(cherry picked from commit e39dfa550d)
(cherry picked from commit 0c78c8c5ac)
(cherry picked from commit 661cf72db0)
[GITEA] Tidy up archive modal (squash) ctx.Locale
(cherry picked from commit 4bb6ee71f0)
(cherry picked from commit ddafd8fbe3)
(cherry picked from commit 9467a6915f)
(cherry picked from commit e632b10380)
(cherry picked from commit 6609d07591)
(cherry picked from commit c130b8a09a)
(cherry picked from commit 1080de5754)
(cherry picked from commit a9813744d4)
(cherry picked from commit 93232f410a)
(cherry picked from commit 1bf1c6b6c1)
[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)
- 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.
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.
- The RSS Feed icons were placed in a proper button, so that it does
not look "inconsistent". This also makes the problem of the button
being improperly aligned go away.
- The icon that shows on user profiles has not been modified because
of a lack of better implementation ideas.
- Where applicable, the RSS Feed icon was put directly next to the
Follow button (right menu), as both functionalities effectively
share the same purpose.
- Despite the attempt at achieving less inconsistency, a conscious
decision to not add any text to those buttons was made, opting for
tooltips instead. "Make it present, but not too annoying."
- A special exception was made for the Releases pages (which contains
text, not a tooltip), where an RSS feed would be particularly
beneficial to users.
The fact that the RSS functionality is explicitly optional was taken
into account, and these improvements were made with public-facing
instances (where the feature works best) in mind.
Fixes https://codeberg.org/forgejo/forgejo/issues/1759
If you are bowing another branch than the default branch and click n the
Code tab, it will take you to the root of the branch. The `BranchName`
variable is also set when viewing a Wiki commit, so we also need to
check if we are on a Wiki.
