- Make the `UserSettings` definition an non-array, this is consistent
with the existing endpoints that uses this definition.
- Resolves#4179
(cherry picked from commit 5926ed1f73)
Currently this string has different amount of placeholders in v8 and v7 because https://codeberg.org/forgejo/forgejo/pulls/3837 was not backported to v7.
### The problem
This string is currently [not translated](https://translate.codeberg.org/translate/forgejo/forgejo/en/?checksum=405b09ee2c2371d4) in every language. For example, when UI is in Slovenian, it would be in English.
But if someone translates it into Slovenian, it will be something like `Posodobljen %s`. Then we merge the Weblate PR, @forgejo-backport-action creates a backport and we forget to check this backport for presence of `repo_updated`. We ship this as a point release of our LTS v7, and then Slovenian users will literally see `Posodobljen %s` in the UI instead of `Posodobljen včeraj`.
By renaming this key in v7 we protect it from these kinds of regressions.
### Test
Go to Explore, look at repo entries, they should contain relative time.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4117
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Reviewed-by: twenty-panda <twenty-panda@noreply.codeberg.org>
Backport #31204 by @silverwind
Using `.segment` on the project columns is a major abuse of that class,
so remove it and instead set the border-radius directly on it.
Fixes: https://github.com/go-gitea/gitea/issues/31129
Co-authored-by: silverwind <me@silverwind.io>
(cherry picked from commit 298d05df3b79634a0364926f34fb02b73d442c31)
Fix#30921
(cherry picked from commit 821d2fc2a3cc897f21d707455850177077b72410)
(cherry picked from commit 50b4e7f26e)
Equivalent to the Gitea v1.22 commit
(cherry picked from commit 8eac16de217978c1f7034f8e360f54d8d638e95e)
When comparing files between the base repo and forked repo, the "blob
excerpt" link should point to the forked repo, because the commit
doesn't exist in base repo.
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit f48cc501c46a2d34eb701561f01d888d689d60d5)
Conflicts:
- templates/repo/diff/section_split.tmpl
- templates/repo/diff/section_unified.tmpl
Resolved the conflict by picking Gitea's change over ours, and
porting it.
- tests/integration/compare_test.go
Kept our test, but picked the "compare all of the relevant
links" part of the Gitea test.
(cherry picked from commit a62a887649)
**Backport:** https://codeberg.org/forgejo/forgejo/pulls/3733
- general English improvements
- separated the header of Language part in user settings into a new string for better translatability
- made that header contain "Default", just like the theme one, because this is how this actually works: the bottom selector saves the language temporarily, the selector in the settings saves it permanently. Not many users know about this difference. This clarification will help some
- removed some of "Manage" from the headers where they aren't really needed. This improves the consistency with some other headers
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3742
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: forgejo-backport-action <forgejo-backport-action@noreply.codeberg.org>
Co-committed-by: forgejo-backport-action <forgejo-backport-action@noreply.codeberg.org>
The previous implementation will start multiple POST requests from the
frontend when moving a column and another bug is moving the default
column will never be remembered in fact.
- [x] This PR will allow the default column to move to a non-first
position
- [x] And it also uses one request instead of multiple requests when
moving the columns
- [x] Use a star instead of a pin as the icon for setting the default
column action
- [x] Inserted new column will be append to the end
- [x] Fix#30701 the newly added issue will be append to the end of the
default column
- [x] Fix when deleting a column, all issues in it will be displayed
from UI but database records exist.
- [x] Add a limitation for columns in a project to 20. So the sorting
will not be overflow because it's int8.
---------
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit a303c973e0264dab45a787c4afa200e183e0d953)
Conflicts:
routers/web/web.go
e91733468ef726fc9365aa4820cdd5f2ddfdaa23 Add missing database transaction for new issue (#29490) was not cherry-picked
services/issue/issue.go
fe6792dff3 Enable/disable owner and repo projects independently (#28805) was not cherry-picked
(cherry picked from commit 7d3ca90dfe)
(cherry picked from commit 084bec89ed7ae0816fc2d8db6784ad22523d1fc4)
1. The previous color contrast calculation function was incorrect at
least for the `#84b6eb` where it output low-contrast white instead of
black. I've rewritten these functions now to accept hex colors and to
match GitHub's calculation and to output pure white/black for maximum
contrast. Before and after:
<img width="94" alt="Screenshot 2024-04-02 at 01 53 46"
src="https://github.com/go-gitea/gitea/assets/115237/00b39e15-a377-4458-95cf-ceec74b78228"><img
width="90" alt="Screenshot 2024-04-02 at 01 51 30"
src="https://github.com/go-gitea/gitea/assets/115237/1677067a-8d8f-47eb-82c0-76330deeb775">
2. Fix project-related issues:
- Expose the new `ContrastColor` function as template helper and use it
for project cards, replacing the previous JS solution which eliminates a
flash of wrong color on page load.
- Fix a bug where if editing a project title, the counter would get
lost.
- Move `rgbToHex` function to color utils.
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: Giteabot <teabot@gitea.io>
---
Conflict resolution: Trivial.
(cherry picked from commit 36887ed3921d03f1864360c95bd2ecf853bfbe72)
(cherry picked from commit f6c0c39f1a)
**Backport:** https://codeberg.org/forgejo/forgejo/pulls/3739
This text can have different forms in other languages depending on context.
The commit also contains a change to .editorconfig to prevent EoF changes when mass-replacing strings, as that causes unintentional merge conflicts with Weblate.
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3750
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: forgejo-backport-action <forgejo-backport-action@noreply.codeberg.org>
Co-committed-by: forgejo-backport-action <forgejo-backport-action@noreply.codeberg.org>
When expanding code diffs, the expansion should search for more context
in the commits repo, rather than in the repo in context, because the
commit may not be available in the base repo. For example, when
previewing a pull request, the commit is not in the target repo yet -
it's in the fork.
Fixes#3746.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 220c3fe3b3)
In
801792e4dc Rename Str2html to SanitizeHTML and clarify its behavior (followup)
the replacement was incorrect because
c9d0e63c20 Remove unnecessary "Str2html" modifier from templates
was not applied and Str2html should have not been present in the first
place.
Fixes: https://codeberg.org/forgejo/forgejo/issues/3554
(cherry picked from commit 337f4f9d87)
When rendering templates for packages, be more forgiving about missing
metadata. For some repository types - like maven - metadata is uploaded
separately. If that upload fails, or does not happen, there will be no
metadata.
In that case, Forgejo should handle it gracefully, and render as much of
the information as possible, without erroring out. Rendering without
metadata allows one to delete a partial package, while if we throw
errors, that becomes a whole lot harder.
This patch adjusts the generic metadata template, and also the maven
template. There may be more cases of the same problem lying around.
Fixes#3663.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit ac4d535dbf)
Before, we would just throw 500 if a user passes an attachment that is
not an allowed type. This commit catches this error and throws a 422
instead since this should be considered a validation error.
(cherry picked from commit 872caa17c0a30d95f85ab75c068d606e07bd10b3)
Conflicts:
tests/integration/api_comment_attachment_test.go
tests/integration/api_issue_attachment_test.go
trivial context conflict because of 'allow setting the update date on issues and comments'
(cherry picked from commit 9cd0441cd3)
The current format makes the text look somewhat like this:
```
testing.yml #15065 :Commit 103306f00c pushed by n0toose
```
This looks wrong. We will have to work on that list at a later point
in time anyways, as well as make the way that we separate information
in subheaders in lists like this one more consistent.
However, this should do for now.
This change should make each entry look like this instead:
```
testing.yml #15065 - Commit 103306f00c pushed by n0toose
```
(cherry picked from commit 870a1c85c7)
Fixes https://github.com/go-gitea/gitea/issues/30664.
Previous use was not a supported way by fomantic and the misuse only
became visible after the checkbox migration.
(cherry picked from commit 1a2ae64b16f10b8d1e17197d18b9eb373faf58db)
Using "data-target", it is possible to set a value to a target element
that can enable it or disable it. Using "data-context" lets us perform
the opposite action on a different target.
Before, only the #external_wiki_box target was used, which was enabled
or disabled depending on whether the user has chosen to use the internal
wiki or the external wiki. If the user chooses to use the internal wiki,
they will disable the box that lets them enter a link pointing to an
external wiki, and vice versa. Although it is not possible to use, say,
boolean operations, we can introduce a target that is
called #globally_writeable_checkbox that gets enabled when
the #external_wiki_box box is disabled, and vice versa.
This makes the box's behavior more consistent with the behavior in the
"Issues" section. To keep things consistent with that section, a new
property was assigned to the "globally_writeable_checkbox" that makes
the box go a bit further in (`tw-pl-4`).
(cherry picked from commit 103306f00c)
and the add more button is on the right
This fix moves the settings button back to the right and the add more
button back to the left.
(cherry picked from commit fb5e36bc6f)
When all repository units are deactivated except for the code unit, the activity tab will not be shown.
Since the activities tab also shows contributing stats, it would be good to show the activities tab also when only code is active.
This commit changes the behavior when the activities tab is shown.
Previous it would only be shown when Issues, Pull-Requests or Releases are activated. Now it would additionally be shown when the code unit is activated.
Refs: #3429
| Before (Code + Issues - Owner) | Before (Code - Viewer) | After (Code + Issues - Owner) | After (Code - Viewer) |
| -- | -- | -- | -- |
|  |  |  |  |
| | `/activity` returns 404 for everyone |  | - |
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3455
Reviewed-by: Otto <otto@codeberg.org>
Co-authored-by: Beowulf <beowulf@beocode.eu>
Co-committed-by: Beowulf <beowulf@beocode.eu>
(cherry picked from commit c54896ba70)
This will move the settings button back to the right, like known from
older versions.
For this, the overflow-menu was changed when a setting button is
available. If no settings button is available, the behavior will not
change.
Fixes#3301
(cherry picked from commit f9628f883d)
Gusted