* split into testPullMergeForm which can be called directly if
the caller wants to specify extra parameters.
* testPullMergeForm can expect something different than StatusOK
* http.StatusMethodNotAllowed can be expected: only retry if the
error message is "Please try again later"
* split into doAPIMergePullRequestForm which can be called directly if
the caller wants to specify extra parameters.
Use the same padding horizontally and vertically, so the views like readme look a bit nicer. Just slightly adjusted two values, nothing really test-able here.
## Motivation
I came to the conclusion that they should be the same myself, later I checked GitHub and it turned out to also use the same paddings. I would like to notice that the padding here (2em = 32px) is the same as GitHub uses too.
I find this as a logical UI change because the paddings are usually same on both axis across the UI (like on PR sidebar).
Also updated paddings for when the files are shown in profile, but copied the `1.5em` that GitHub uses. This, once again, makes sense, because the overview markdown isn't the primary content, or as primary as the readme on the repo is, taking the full usable width.
## Preview
https://codeberg.org/attachments/55f6685c-1978-410a-a17b-9fac91f0642e
---
https://codeberg.org/attachments/d9016a1c-13cf-4ea6-a8e4-2619d93f3560
## Note
`.non-diff-file-content .plain-text` is left untouched with `1em 2em`, because the plaintext seems to add it's own margins, so it would make it look worse.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3944
Reviewed-by: Otto <otto@codeberg.org>
Reviewed-by: Beowulf <beowulf@noreply.codeberg.org>
Remove CSS code that was made unused by some changes in Gitea. I was working on a layout change here but was bothered a bit by these. I dug a bit into the git history to find out how they were made unused but it's relatively uneasy.
- remove rule that was setting `width: 100%;`: the exactly same selector setting this exact value is duplicated below
- remove rules with `followers` in selectors: we don't use this class in templates (would be nice if someone double-checks)
- my editor forced EoF fix
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3937
Reviewed-by: Beowulf <beowulf@noreply.codeberg.org>
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
### After
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>
