Follow-up of #2282 and #2296 (which tried to address #2278)
One of the issue with the previous PR is that when a conversation on the Files tab was marked as "resolved", it would fetch all the comments for that line (even the outdated ones, which should not be shown on this page - except when explicitly activated).
To properly fix this, I have changed `FetchCodeCommentsByLine` to `FetchCodeConversation`. Its role is to fetch all comments related to a given (review, path, line) and reverted my changes in the template (which were based on a misunderstanding).
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/2306
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: oliverpool <git@olivier.pfad.fr>
Co-committed-by: oliverpool <git@olivier.pfad.fr>
- Backport of #2100
- Make the reference URL in the "Reference in New issue" feature
absolute again as it wouldn't render as a link otherwise.
- Adds integration test.
- Regression by 769be877f2
- Resolves#2012
(cherry picked from commit c74bae2897)
Backport #28351 by @KN4CK3R
Fix#28347
As there is no info how to reproduce it, I can't test it.
Fix may be `section_split.tmpl @ 126/130`.
Other changes are "empty check" refactorings.
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
(cherry picked from commit 08445d5d86)
- The review type '22' is a general comment type that is attached to
single codecomments, reviews with multiple comments or to simple approve
and request changes comment. This comment can be used to create a link
towards this action on an pull request.
- Adds an anchor to the review comment type, so that when its getting
linked to it, it actually jumps towards that event.
- This also now fixes the behavior that after you created a review you
will be redirected to that review and because this is an general comment
type other mails will also be 'fixed' such as the approved or request
changes.
- Resolves https://codeberg.org/forgejo/forgejo/issues/1248
(cherry picked from commit 1741a5f1fe)
---------
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-authored-by: Caesar Schinas <caesar@caesarschinas.com>
(cherry picked from commit 89c9a498fd)
(cherry picked from commit a2e2ce79f4)
(cherry picked from commit 299e437379)
(cherry picked from commit 91a224ce2d)
(cherry picked from commit 3a89b23b3b)
Backport #27927 by @invliD
When an assignee changed event comment is rendered, most of it is
guarded behind the assignee ID not being 0. However, if it is 0, that
results in quite broken rendering for that comment and the next one.
This can happen, for example, when repository data imported from outside
of Gitea is incomplete.
This PR makes sure comments with an assignee ID of 0 are not rendered at
all.
---
Screenshot before:
<img width="272" alt="Bildschirmfoto 2023-11-05 um 20 12 18"
src="https://github.com/go-gitea/gitea/assets/42910/7d629d76-fee4-4fe5-9e3a-bf524050cead">
The comments in this screenshot are:
1. A regular text comment
2. A user being unassigned
3. A user being assigned
4. The title of the PR being changed
Comments 2 and 3 are rendered without any text, which indents the next
comment and does not leave enough vertical space.
Co-authored-by: Sebastian Brückner <code@nik.dev>
Backport #27265 by @JakobDev
Part of #27065
This PR touches functions used in templates. As templates are not static
typed, errors are harder to find, but I hope I catch it all. I think
some tests from other persons do not hurt.
Co-authored-by: JakobDev <jakobdev@gmx.de>
Backport #27227 by @denyskon
Throughout the Gitea codebase, you can meet some weird constructions to
make `locale.Tr` work in subtemplates.
Since we now have `ctx.Locale.Tr` which solves that problem, clean up
various templates which pass `locale` through `dict` or use some weird
constructions like `$.root.locale`
Going on, it would be great to replace every case of `$.locale.Tr` and
`.locale.Tr` with `ctx.Locale.Tr`, but that needs to be done with
patience.
Co-authored-by: Denys Konovalov <kontakt@denyskon.de>
1. Use `gt-invisible` instead of `invisible`.
2. Use `gt-word-break` instead of `dont-break-out` (there is a slight
different "hyphens", but I think it won't affect too much since it is
only used for the "full name").
3. Remove `.small.button:has(svg)` , now our buttons could layout SVG
correctly, and actually I didn't see this CSS class is used in code.
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>
This problem occurs because in #25839, the warning status has been
removed, but there is something in the tmpl that hasn't been changed.
related #25839close#26118
this will allow us to fully localize it later
PS: we can not migrate back as the old value was a one-way conversion
prepare for #25213
---
*Sponsored by Kithara Software GmbH*
So I found this [linter](https://github.com/Riverside-Healthcare/djlint)
which features a mode for go templates, so I gave it a try and it did
find a number of valid issue, like unbalanced tags etc. It also has a
number of bugs, I had to disable/workaround many issues.
Given that this linter is written in python, this does add a dependency
on `python` >= 3.8 and `poetry` to the development environment to be
able to run this linter locally.
- `e.g.` prefixes on placeholders are removed because the linter had a
false-positive on `placeholder="e.g. cn=Search"` for the `attr=value`
syntax and it's not ideal anyways to write `e.g.` into a placeholder
because a placeholder is meant to hold a sample value.
- In `templates/repo/settings/options.tmpl` I simplified the logic to
not conditionally create opening tags without closing tags because this
stuff confuses the linter (and possibly the reader as well).
Fix#25133
Thanks @wxiaoguang @silverwind.
I'm sorry I made a mistake, it will be fixed in this PR.
---------
Co-authored-by: Giteabot <teabot@gitea.io>
Co-authored-by: silverwind <me@silverwind.io>
Fixes https://github.com/go-gitea/gitea/issues/25130
The old code uses `$(this).next()` to get `dismiss-review-modal`.
At first, it will get `$(#dismiss-review-modal)`, but the next time it
will get `$(#dismiss-review-modal).next();`
and then `$(#dismiss-review-modal).next().next();`.
Because div `dismiss-review-modal` will be removed when
`dismiss-review-btn` clicked.
Maybe the right usage is adding `show-modal` class and `data-modal`
attribute.
This adds the ability to pin important Issues and Pull Requests. You can
also move pinned Issues around to change their Position. Resolves#2175.
## Screenshots
The Design was mostly copied from the Projects Board.
## Implementation
This uses a new `pin_order` Column in the `issue` table. If the value is
set to 0, the Issue is not pinned. If it's set to a bigger value, the
value is the Position. 1 means it's the first pinned Issue, 2 means it's
the second one etc. This is dived into Issues and Pull requests for each
Repo.
## TODO
- [x] You can currently pin as many Issues as you want. Maybe we should
add a Limit, which is configurable. GitHub uses 3, but I prefer 6, as
this is better for bigger Projects, but I'm open for suggestions.
- [x] Pin and Unpin events need to be added to the Issue history.
- [x] Tests
- [x] Migration
**The feature itself is currently fully working, so tester who may find
weird edge cases are very welcome!**
---------
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: Giteabot <teabot@gitea.io>
There was some recent discussion about this in Discord `ui-design`
channel and the conclusion was that
https://github.com/go-gitea/gitea/issues/24305 should have fixed their
OS font installation to have semibold weights.
I have now tested this 601 weight on a Windows 10 machine on Firefox
myself, and I immediately noticed that bold was excessivly bold and
rendering as 700 because browsers are biased towards bolder fonts. So
revert this back to the previous value.
