When performing migrations, and need to remap external users to local
ones, when no local mapping is possible, map the external user to Ghost,
rather than the user who initiated the migration.
Mapping the external user to the migration initiator has the potential
of breaking assumptions elsewhere, like only having one review per pull
request per user. Mapping these migrated, locally unavailable users to
Ghost makes sure these - often hidden - assumptions do not break.
Fixes#3860.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
When installing Forgejo via the on-line installer, force
DisableRegistration to true, to discourage creating instances with open
registration. Because open registration requires constant vigil to fight
off spammers of all kinds, it is not a great default. It should be a
conscious decision. This change is made in an effort to make the choice
of running an instance with open registration a conscious choice, rather
than simply the default.
Partially addresses #3925.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Having an instance with open registration requires work, otherwise it
will be overrun by spammers of all kinds. Yet, the setting to disable
open registration on the installation page is hidden behind "optional
settings", a place hardly anyone ever looks.
To improve the situation, lift the setting out of that, and place it
more prominently, just above the update checker setting.
Partially addresses #3925.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Following gitea#28981, set `X-Forgejo-Sender` and `X-Forgejo-Recipient`
to the username of the respective users, rather than their display name.
The username is more appropriate for these headers, for filtering
purposes. The display name is already included in the From header.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Cherry-pick of 2ced31e81d adapted to Forgejo releases UI.
Percentage-based `border-radius` [creates undesirable
ellipse](https://jsfiddle.net/silverwind/j9ko5wnt/4/) on non-square
content. Instead, use pixel value and use same wording `full` like
tailwind does, but increast to 99999px over their 9999px.
(cherry picked from commit 2ced31e81dd9e45659660c1abff529d0192fd8ed)
These are some slight design changes to how usercards are presented.
- `margin`: removed one of the sides so the margins are the same in both axis
- `margin`: increased from 10px to 15px
Previously it was (Y, X) = (20, 10); now it's (15, 15)
- `width`: slightly decreased so that the point, where too small screen width causes card relocation to another row, doesn't increase
- `padding`: this change does nothing visually. `padding-bottom` was useless because padding was already set for all sides by another rule `.ui.segment {padding: 1em};`. This change just ensures that padding stays the same for all sides even if `.ui.segment` changes, instead of causing inconsistency
- `margin-bottom`: added as an override to margin caused by `display: flex`. From my research, usually there's `25px` gap between the content and the pagination. It was `39px` here, now it's `25px` too
### Before
![image](/attachments/0ebf6f44-6b27-4d4d-8856-77568291518c)
### After
![image](/attachments/1e0a3d95-ac49-4d10-8e00-86cc041d4338)
I can't show the distance between the content and the pagination, but the change does work when applying via devtools on https://codeberg.org/forgejo/forgejo/stars.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3915
Reviewed-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@noreply.codeberg.org>
Reviewed-by: Caesar Schinas <caesar@caesarschinas.com>
It was premature to try to use them, try again later.
https://codeberg.org/forgejo-integration/forgejo/actions/runs/2147
github.com/docker/buildx v0.14.1 59582a88fca7858dbe1886fd1556b2a0d79e43a3
::endgroup::
[command]/usr/bin/docker buildx build --build-arg RELEASE_VERSION=8.0-test --file Dockerfile --iidfile /tmp/docker-actions-toolkit-UzuWxS/iidfile --platform linux/amd64,linux/arm64,linux/arm/v6 --tag codeberg.org/***/forgejo:8.0-test --metadata-file /tmp/docker-actions-toolkit-UzuWxS/metadata-file --push .
------
> [linux/arm/v6 internal] load metadata for code.forgejo.org/oci/golang:1.22-alpine3.20:
------
Dockerfile:3
--------------------
1 | FROM --platform=$BUILDPLATFORM docker.io/tonistiigi/xx AS xx
2 |
3 | >>> FROM --platform=$BUILDPLATFORM code.forgejo.org/oci/golang:1.22-alpine3.20 as build-env
4 |
5 | ARG GOPROXY
--------------------
Dockerfile:1
--------------------
1 | >>> FROM --platform=$BUILDPLATFORM docker.io/tonistiigi/xx AS xx
2 |
3 | FROM --platform=$BUILDPLATFORM code.forgejo.org/oci/golang:1.22-alpine3.20 as build-env
--------------------
Dockerfile:54
--------------------
52 | RUN chmod 644 /go/src/code.gitea.io/gitea/contrib/autocompletion/bash_autocomplete
53 |
54 | >>> FROM code.forgejo.org/oci/golang:1.22-alpine3.20
55 | ARG RELEASE_VERSION
56 | LABEL maintainer="contact@forgejo.org" \
--------------------
ERROR: failed to solve: code.forgejo.org/oci/golang:1.22-alpine3.20: failed to resolve source metadata for code.forgejo.org/oci/golang:1.22-alpine3.20: no match for platform in manifest: not found
::error::buildx failed with: ERROR: failed to solve: code.forgejo.org/oci/golang:1.22-alpine3.20: failed to resolve source metadata for code.forgejo.org/oci/golang:1.22-alpine3.20: no match for platform in manifest: not found
Syncs up docs associated to actions and deleted branch cleanup i.e. in
custom/app.example.ini and the config cheat sheet.
(cherry picked from commit c9eac519961ecd5d0e1d6ee856ab532e8c16c65d)
Conflicts:
docs/content/administration/config-cheat-sheet.en-us.md
docs do not exist here in Forgejo
To try it you need **nix** installed `nix-daemon ` running and your user
has to be member of the **nix-users** group. Or use NixOS.
then by just:
```sh
nix develop -c $SHELL
```
a dedicated development environment with all needed packages will be
created.
(cherry picked from commit de6f0488a67ad65bd2ac40356b08a78a365414cd)
Do not try to create a new authorization grant when one exists already,
thus preventing a DB-related authorization issue.
Fix https://github.com/go-gitea/gitea/pull/30790#issuecomment-2118812426
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
(cherry picked from commit 9c8c9ff6d10b35de8d2d7eae0fc2646ad9bbe94a)
Replace #25741Close#24445Close#30658Close#20646
~Depends on #30805~
Since #25741 has been rewritten totally, to make the contribution
easier, I will continue the work in this PR. Thanks @6543
---------
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit c6cf96d31d80ab79d370a6192fd761b4443daec2)
Conflicts:
tests/integration/editor_test.go
trivial context conflict because of 75ce1e2ac1 [GITEA] Allow user to select email for file operations in Web UI
tests/integration/pull_merge_test.go
trivial context conflicts in imports because more tests were added in Forgejo
From
https://github.com/go-gitea/gitea/issues/31018#issuecomment-2119622680.
This commit removes the link to a deleted branch name because it returns
a 404 while it is in this deleted state. GitHub also throws a 404 when
navigating to a branch link that was just deleted, but this deleted
branch is removed from the branch list after a page refresh. Since with
Gitea this deleted branch would be kept around for quite some time
(well, until the "cleanup deleted branches" cron job begins), it makes
sense to not have this as a link that users can navigate to.
(cherry picked from commit 1007ce764ea80b48120b796175d7d1210cbb6f74)
Remove "EncodeSha1", it shouldn't be used as a general purpose hasher
(just like we have removed "EncodeMD5" in #28622)
Rewrite the "time-limited code" related code and write better tests, the
old code doesn't seem quite right.
(cherry picked from commit fb1ad920b769799aa1287441289d15477d9878c5)
Conflicts:
modules/git/utils_test.go
trivial context conflict because sha256 testing in Forgejo has diverged
Fix#30992
(cherry picked from commit 47accfebbd69e5f47d1b97a3e39cf181fab7e597)
Conflicts:
models/unit/unit.go
trivial context conflict because of
e07b0e75ff Add a direct link from repo header to unit settings
When creating a repo, the "FORCE_PRIVATE" config option should be
respected, `readonly` doesn't work for checkbox, so it should use
`disabled` attribute.
(cherry picked from commit edbf74c418061b013a5855f604dd6be6baf34132)
Conflicts:
templates/repo/create.tmpl
templates/repo/migrate/codebase.tmpl
templates/repo/migrate/git.tmpl
templates/repo/migrate/gitbucket.tmpl
templates/repo/migrate/gitea.tmpl
templates/repo/migrate/github.tmpl
templates/repo/migrate/gitlab.tmpl
templates/repo/migrate/gogs.tmpl
templates/repo/migrate/onedev.tmpl
already in forgejo fc0c5e80da Fix and improve repo visibility checkbox when FORCE_PRIVATE is on (#3786)
enforcing FORCE_PRIVATE on repo settings was manually tested
with a repository of an unprivileged user after setting
FORCE_PRIVATE = true
Mostly cap fixes and a few improvements.
As for `activity.active_prs_count_`, it currently looks like this in the UI, I fixed it:
![image](/attachments/5d2dc089-519e-4655-8f8b-f78964ff179a)
Although I'm also the person who [introduced](4c1af0d9a6) the inconsistency.
`send_reset_mail` is a button, removed redundant word from it. It would be good to refactor such keys, but it will be an impossibly long process. Anyway, key refactors are done in separate PRs for easier merges.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3912
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
the test file used has a size below the default threshold and will
never be compressed because of that, regardless of its extension. Reduce
the threshold to 10 bytes otherwise the test is a false positive.
regression from 767e9634d3. It changed
the parsing of the [admin] section from being derived from the content
of each key with mustMapSetting(rootCfg, "admin", &Admin) to
explicitly listing all keys in the code.
SEND_NOTIFICATION_EMAIL_ON_NEW_USER was not added and therefore
ignored. As a consequence notifications of newly registered users were
never sent.
There is no need to pin a specific patch version for testing. The
worst that can happen in this context is that the CI fails and it can
be addressed in this context. It will not impact releases.