Previously, the repo wiki was hardcoded to use `master` as its branch,
this change makes it possible to use `main` (or something else, governed
by `[repository].DEFAULT_BRANCH`, a setting that already exists and
defaults to `main`).
The way it is done is that a new column is added to the `repository`
table: `wiki_branch`. The migration will make existing repositories
default to `master`, for compatibility's sake, even if they don't have a
Wiki (because it's easier to do that). Newly created repositories will
default to `[repository].DEFAULT_BRANCH` instead.
The Wiki service was updated to use the branch name stored in the
database, and fall back to the default if it is empty.
Old repositories with Wikis using the older `master` branch will have
the option to do a one-time transition to `main`, available via the
repository settings in the "Danger Zone". This option will only be
available for repositories that have the internal wiki enabled, it is
not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`.
When migrating a repository with a Wiki, Forgejo will use the same
branch name for the wiki as the source repository did. If that's not the
same as the default, the option to normalize it will be available after
the migration's done.
Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will
now include the wiki branch name in `GET` requests, and allow changing
the wiki branch via `PATCH`.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit d87c526d2a313fa45093ab49b78bb30322b33298)
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 4b744399229f255eb124c22e3969715046043209)
(cherry picked from commit 337cf62c1094273ab61fbaab8e7fb41eb6e2e979)
(cherry picked from commit b6786fdb3246a3a455b59149943807c1f13a028a)
(cherry picked from commit a5d2829a1027afd593fd855a8e2d7d7cd38234b8)
[GITEA] Optionally allow anyone to edit Wikis (squash) AddTokenAuth
(cherry picked from commit fed50cf72eaaa00ef1f4730f9b12a64a10b66113)
(cherry picked from commit 42c55e494e1018a210e54d405c15eec24a0b37c7)
(cherry picked from commit e3463bda47ffee4ab57efadfe5094f9401541cfd)
- Make it consistent with the other modals of the dangerous actions.
(cherry picked from commit 576d7ec759baefd2382d565212c3168e38bbdd75)
(cherry picked from commit 8b1225f9742cc0d3942824895923cbc8e9d49d04)
(cherry picked from commit c2c47972ee492686842b1623f9fe941a0e599f0a)
(cherry picked from commit eec301806b925388585546edc6407e3f6d644f44)
(cherry picked from commit 6b5e728f0aaa87e2711c1c2d2111446fc412e0ca)
(cherry picked from commit 3681691e65a73ef59205b066320c9ce58d4d80e4)
(cherry picked from commit e39dfa550d691ff73a05a507d4cb2fd073940088)
(cherry picked from commit 0c78c8c5ac6970495cde3e2737ed05b200e02f5a)
(cherry picked from commit 661cf72db07039abde51e03dc43a89e240cebae0)
[GITEA] Tidy up archive modal (squash) ctx.Locale
(cherry picked from commit 4bb6ee71f0f0a45d70fed048444f0b1ae0f4ded0)
(cherry picked from commit ddafd8fbe3fca0469d846aa4b65ed53675f2304e)
(cherry picked from commit 9467a6915fe362057958982e7fb381f1cf5d9c98)
(cherry picked from commit e632b10380bb00ffddd6e917ab150515a5c6d251)
(cherry picked from commit 6609d075914a5d897afa59924f9e16b7a9710501)
(cherry picked from commit c130b8a09a6f5a1fcc71fc0bbbb7738ca70774ec)
(cherry picked from commit 1080de57542b4685d849ebb6bc4d900a770a22a8)
(cherry picked from commit a9813744d4e1e08a0229a4749e6fca7d9a4d1de6)
(cherry picked from commit 93232f410a639a2aa7ecff6299f202cd07e2a920)
(cherry picked from commit 1bf1c6b6c134b9a6b4f8a28a3dac0fdcdd2fe749)
(cherry picked from commit cb703ac2926e6f40da6fa68eadcdfc0ffe8cc414)
(cherry picked from commit ac487970292a40fd2cce125b1ae43299010dffa4)
[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 c38dbd6f889aeb52745eddb276225acd0153cba6)
(cherry picked from commit 7c07592d01b086b612195367c6a13560e5539767)
(cherry picked from commit 78637af2b6440ae307de5e21b284c08c02dd4d13)
[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 bf679b24dd23c9ed586b9439e293bbd27cc89232)
(cherry picked from commit 1963085dd9d1521b7a4aa8558d409bd1a9f2e1da)
(cherry picked from commit fb94095d1992c3e47f03e0fccc98a90707a5271b)
(cherry picked from commit e1d1e46afee6891becdb6ccd027fc66843b56db9)
(cherry picked from commit 93993029e4ec8a20a8bc38d80bb4b801e52ee1b7)
(cherry picked from commit df3b058179d8f3e06cc6fb335b287c72c8952821)
(cherry picked from commit 8ccc6b9cba46a736665e4b25523da0baf1679702)
(cherry picked from commit 9fbe28fca35e3d02c23521e063679775ec0792f8)
(cherry picked from commit 4ef2be6dc705c693735e024b28fd7dac3de39d47)
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 83cae67aa3fe8f9eb732f86020e58b9ea4d8b5ec)
(cherry picked from commit 447009ff568a542985f6b3a9bc7237b9de3e3c54)
(cherry picked from commit 72c0a6150aee7c3a965c87e7348faa2b48c520de)
(cherry picked from commit 8ee9c070b98f64263d63dfef32d54bdad5f0d266)
(cherry picked from commit 89aba06403be898adbfff6b2d7bb01aad239a87c)
(cherry picked from commit 798407599f3d77bdd8bad5fa7abba81d417cd916)
(cherry picked from commit 41c9a2606bd8d7036e7d54ad7ab35af06ec99a34)
(cherry picked from commit a57b214e366435240c4a210115c6a3fda0d37f8b)
(cherry picked from commit fd287a91349bc7844544f9b6ff88e46157d3dc80)
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>
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.
This PR adds a new field `RemoteAddress` to both mirror types which
contains the sanitized remote address for easier (database) access to
that information. Will be used in the audit PR if merged.
1. There is already `gt-ac`, so no need to introduce `flex-item-center`
2. The `flex-item-baseline` and `.flex-item-icon svg { margin-top: 1px
}` seem to be a tricky patch, they don't resolve the root problem, and
still cause misalignment in some cases.
* The root problem is: the "icon" needs to align with the sibling
"title"
* So, make the "icon" and the "title" both have the same height
3. `flex-text-inline` could only be used if the element is really
"inline", otherwise its `vertical-align` would make the box size change.
In most cases, `flex-text-block` is good enough.
---------
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: Giteabot <teabot@gitea.io>
1. In many cases, the `flex-list` has previous and next `gt-hidden`
siblings, so relax the CSS selector to remove all ".segument .flex-list"
paddings.
2. Make the "Add key" button can toggle
3. Move help message into the related segment(panel). Otherwise users
would misread the message, eg: the SSH help seemed for GPG because they
are so near
4. Move modal element into the segment element, otherwise it affects the
layout
I noticed that the code of several new webhook pages is highly
repetitive, so I pulled out the common parts to a new template, unified
reference, unified maintenance
---------
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
Each change is tested manually line by line. There are too many changes
so I can't share dozens of screenshots.
In short:
1. `ui right` could be still used in `ui top attached header`, because
there is a special case.
2. A lot of `ui right` are just no-op, so they can be removed safely.
3. Some of the `ui right` should be replaced by `gt-float-right` (to
avoid breaking, leave them to the future).
4. A few of the `ui right` could be rewritten by flex.
Fix#26731
Almost all "tabindex" in code are incorrect.
1. All "input/button" by default are focusable, so no need to use "tabindex=0"
2. All "div/span" by default are not focusable, so no need to use "tabindex=-1"
3. All "dropdown" are focusable by framework, so no need to use "tabindex"
4. Some tabindex values are incorrect (eg: `new_form.tmpl`), so remove them
Co-authored-by: Giteabot <teabot@gitea.io>
I kept sending pull requests that consisted of one-line changes. It's
time to
settle this once and for all. (Maybe.)
- Explain Gitea behavior and the consequences of each
setting better, so that the user does not have to consult
the docs.
- Do not use different spellings of identical terms
interchangeably, e.g. `e-mail` and `email`.
- Use more conventional terms to describe the same things,
e.g. `Confirm Password` instead of `Re-Type Password`.
- Introduces additional clarification for Mirror Settings
- Small adjustments in test
- This is a cry for help.
- Grammar and spelling consistencies for en-US locale
(e.g. cancelled -> canceled)
- Introduce tooltip improvements.
---------
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Giteabot <teabot@gitea.io>
Fixed two incorrect headers for setting the page navigation bar:
* User settings page, should not use the title "`org.settings`"
* Repo settings page, should not use the title "`org.settings`"
releated to #21820
- Split `Size` in repository table as two new colunms, one is `GitSize`
for git size, the other is `LFSSize` for lfs data. still store full size
in `Size` colunm.
- Show full size on ui, but show each of them by a `title`; example:
- Return full size in api response.
---------
Signed-off-by: a1012112796 <1012112796@qq.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: DmitryFrolovTri <23313323+DmitryFrolovTri@users.noreply.github.com>
Co-authored-by: Giteabot <teabot@gitea.io>
