- If `GetAffectedFiles` is called for a push with an empty oldCommitID,
then set the oldCommitID to the empty tree. This will effictively diff
all the changes included in the push, which is the expected behavior for
branches.
- Integration test added.
- Resolves#5683
- Port of gitea#31778 but implemented differently.
Make the big move to Eslint flat config format. The outcome of Eslint
still should be the same, but some things has changed:
- `eslint-plugin-github` is dropped, flat configs have been out for a
while and most eslint plugins support it, but for no reason and no
activity in sight this plugin is likely not going to support flat config
for a while and to avoid other plugins not being able to update (as they
are requiring flat configs) drop the github rules.
- Nested configs don't work properly and are unified into the root
eslint config, this unification did cause some conflicts and thats why
the `import-x` is in a seperate 'group' to exclude targeting Vue files.
- The `eslint-plugin-i` is deprecated and `esplint-plugin-import-x` is
its succesor which has better support for flat configs, the same rules
are still applied.
The majority of the flat config was generated by
`@eslint/migrate-config` tool.
- Use the combo markdown editor for the milestone description. The
milestone description is rendered in markdown, so it makes sense to use
a 'markdown-aware' editor. This also includes the option to use
monospace font.
- Resolves#5649
- When a truncated comment is detected in the RSS/Atom feeds, fetch the
comment from the database and use the original content.
- Added integration test.
- Resolves#5650
Since they are written to the milestone that is still open, there is
no risk of confusing them with final release notes. Such a distinction
is more relevant when in the context of a release notes file committed
to the repository.
* added a message for the case where the user's profile is private but the Public activity is not hidden
The activity is still hidden anyway because the profile is private, but previously the message would say:
`Your activity is visible to everyone, except for interactions in private spaces...`
which I would consider as a flaw of the original implementation. Now it will say:
`Your activity is only visible to you and the instance administrators because your profile is private...`
* started showing the message for admins that the activity they see should remain private in the case
where the whole profile is private, not just the activity tab. Previously it would say:
This activity is visible to everyone, but as an administrator you can also see interactions in private spaces.`
which I would also consider as a flaw of the original implementation. Now it will say:
`This activity is visible to you because you're an administrator, but the user wants it to remain private.`
* added test cases
* bumped up the number of our GPL-licensed files
Preview
For both screenshots, Forgejo would previously display misinformation.
Change 1: User viewing their private profile, but activity isn't configured as hidden
https://codeberg.org/attachments/6659c80c-15dd-48be-a379-db737fd1dd5e
Change 2: Admin viewing user's private profile
https://codeberg.org/attachments/220da57f-b658-4474-9ad2-049e8438a0af
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/5638
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
- When an admin wants syncronize tags in the Git data to the database
via the admin dashboard all annoted tags loses their title. This was
caused because the code didn't correctly handle annoted tags. Annoted
tags have their own objectID to store the annoted message, unlike
'normal' tags which point to the commitID. While the function was being
run for annoted tags, the code thought it found a mismatch in the
objectIDs, because the stored version was actually correct which pointed
to the commitID but the code found the objectID of the annoted tag.
- Make `SyncReleasesWithTags` corectly handle annoted tags.
- Added unit and integration tests.
- Resolves#5628
This change does not bring the desired benefit, because the button is
reinitialized from a Vue component once loaded, overriding this change
and causing a visual glitch upon page load (the button is moving its
position).
See the comment:
> this code must match the code in BranchTagSelector.vue
This button is also used in other places such as the release list where
the additional margin does not fit well. As such, this needs a new
solution.
This reverts commit 18cad9d342.
