`HookEventType` of pull request review comments should be
`HookEventPullRequestReviewComment` but some event types are
`HookEventPullRequestComment` now.
It use old en-US locales as reference, fill the old other locales with
new locales.
----
## More broken translations
Many translations are still broken. The reason is: at the last time
restoring the ini to crowdin, many semicolon are treated as comments.
Two kinds of broken strings:
### Some translations can be re-translated
<details>
```
skipping options/locale/locale_si-LK.ini org teams.add_nonexistent_repo
skipping options/locale/locale_tr-TR.ini repo commits.search.tooltip
skipping options/locale/locale_es-ES.ini repo settings.trust_model.committer.desc
skipping options/locale/locale_es-ES.ini admin dashboard.new_version_hint
skipping options/locale/locale_pt-PT.ini org teams.add_nonexistent_repo
skipping options/locale/locale_hu-HU.ini install require_sign_in_view_popup
skipping options/locale/locale_hu-HU.ini repo migrate.invalid_local_path
skipping options/locale/locale_id-ID.ini repo migrate.invalid_local_path
skipping options/locale/locale_id-ID.ini org teams.add_nonexistent_repo
skipping options/locale/locale_de-DE.ini repo settings.protect_protected_file_patterns_desc
```
</details>
So this PR also does some small changes on them, to trigger the
re-translation.
### The `locale_el-GR.ini` contains many broken tranlsations
I guess we should reset them from crowdin side, then translators can
re-translate them.
----
Update: in latest main, the strings have been fixed.
## TODO
Update: the el-GR translators have done great job and fixes these broken
translations.
<details>
Merge this PR ASAP and upload `locale_el-GR.ini` to crowdin to remove
broken strings.
Out-dated, fixed in main.
</details>
---------
Co-authored-by: delvh <dev.lh@web.de>
That's incorrect code caused by Copy&Paste.
`show-modal` / `show-panel` are used by JS to show something, but these
links have `href`, they should navigate to new page.
Close #23657
- **Installation**: includes how to install Gitea and related other
tools, also includes upgrade Gitea
- **Administration**: includes how to configure Gitea, customize Gitea
and manage Gitea instance out of Gitea admin UI
- **Usage**: includes how to use Gitea's functionalities. A sub
documentation is about packages, in future we could also include CI/CD
and others.
- **Development**: includes how to integrate with Gitea's API, how to
develop new features within Gitea
- **Contributing**: includes how to contribute code to Gitea
repositories.
After this is merged, I think we can have a sub-documentation of `Usage`
part named `Actions` to describe how to use Gitea actions
---------
Co-authored-by: John Olheiser <john.olheiser@gmail.com>
Close #23622
As described in the issue, disabling the LFS/Package settings will cause
errors when running `gitea dump` or `gitea doctor`. We need to check the
settings and the related operations should be skipped if the settings
are disabled.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
## TLDR
* Improve performance: lazy creating the tippy instances.
* Transparently support all "tooltip" elements, no need to call
`initTooltip` again and again.
* Fix a temporary tooltip re-entrance bug, which causes showing temp
content forever.
* Upgrade vue3-calendar-heatmap to 2.0.2 with lazy tippy init
(initHeatmap time decreases from 100ms to 50ms)
## Details
### The performance
Creating a lot of tippy tooltip instances is expensive. This PR doesn't
create all tippy tooltip instances, instead, it only adds "mouseover"
event listener to necessary elements, and then switches to the tippy
tooltip
### The general approach for all tooltips
Before, dynamically generated tooltips need to be called with
`initTooltip`.
After, use MutationObserver to:
* Attach the event listeners to newly created tooltip elements, work for
Vue (easier than before)
* Catch changed attributes and update the tooltip content (better than
before)
It does help a lot, eg:
1a4efa0ee9/web_src/js/components/PullRequestMergeForm.vue (L33-L36)
### Temporary tooltip re-entrance bug
To reproduce, on try.gitea.io, click the "copy clone url" quickly, then
the tooltip will be "Copied!" forever.
After this PR, with the help of `attachTippyTooltip`, the tooltip
content could be reset to the default correctly.
### Other changes
* `data-tooltip-content` is preferred from now on, the old
`data-content` may cause conflicts with other modules.
* `data-placement` was only used for tooltip, so it's renamed to
`data-tooltip-placement`, and removed from `createTippy`.
Follow #23037
Fix [#22598
comment](https://github.com/go-gitea/gitea/issues/22958#issuecomment-1475763042)
Workflows with `pull_request` trigger event can't be triggered by
`pull_request_sync` event. This PR adds the `canGithubEventMatch`
function to check if a Github event can match any Gitea event. If the
Github event matches a Gitea event, the related workflows should be
triggered.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Add some review features that are notably missing from Gitlab CE but not
Gitea.
Also add Merge Queues which is not supported by Gitea but is quite an
important feature.
This PR follows #22599 and #23450
The major improvements:
1. The `aria-*.js` are totally transparent now, no need to call
`attachDropdownAria` explicitly anymore.
* It hooks the `$.fn.checkbox` and `$.fn.dropdown`, then our patch
works.
* It makes all dynamically generated checkbox/dropdown work with a11y
without any change
* eg: the `conversation.find('.dropdown').dropdown();` in `repo-diff.js`
2. Since it's totally transparent now, it could be easier to modify or
remove in the future.
3. It handles all selection labels as well (by onLabelCreate), so it
supports "multiple selection dropdown" now.
* It partially completes one of my TODOs: `TODO: multiple selection is
not supported yet.`
4. The code structure is clearer, code blocks are splitted into
different functions.
* The old `attachOneDropdownAria` was splitted into separate functions.
* It makes it easier to add more fine tunes in the future, and co-work
with contributors.
6. The code logic is similar as before, only two new parts:
1. the `ariaCheckboxFn` and `ariaDropdownFn` functions
2. the `onLabelCreate` and `updateSelectionLabel` functions
In `aria-dropdown.js` I had to mix jQuery and Vanilla JS somewhat, I
think the code is still understandable, otherwise the code would be much
more complex to read.
Thanks to fsologureng for the idea about "improving the 'delete icon'
with aria attributes".
If there is anything unclear or incorrect, feel free to ask and discuss,
or propose new PRs for it.
This updates the PR docs and explains how to work with PRs, for those
who may not know.
It was mentioned that this page could explain PRs a bit better, in case
some users are not familiar with GitHub or similar forges.
Signed-off-by: jolheiser <john.olheiser@gmail.com>
Since #23493 has conflicts with latest commits, this PR is my proposal
for fixing #23371
Details are in the comments
And refactor the `modules/options` module, to make it always use
"filepath" to access local files.
Benefits:
* No need to do `util.CleanPath(strings.ReplaceAll(p, "\\", "/"))),
"/")` any more (not only one before)
* The function behaviors are clearly defined
The `q` parameter was not rendered in pagination links because
`context.Pagination:AddParam` checks for existance of the parameter in
`ctx.Data` where it was absent. Added the parameter there to fix it.
Caught by @wxiaoguang in
https://github.com/go-gitea/gitea/pull/23337#issuecomment-1467317742.
Additionally, there were three instances that have the same content as `templates/base/deletion_modal_actions.tmpl` but that are not intended to delete something.
Instead of renaming the template above, these instances were simply re-hard-coded again.
Renaming/improving the template above is left for future PRs.
There are multiple duplicate reports of errors during template rendering
due to broken custom templates.
Unfortunately the error returned here is somewhat difficult for users to
understand and it doesn't return the context of the error.
This PR attempts to parse the error returned by the template renderer to
add in some further context including the filename of the template AND
the preceding lines within that template file.
Ref #23274
---------
Signed-off-by: Andrew Thornton <art27@cantab.net>
Related: #23590
Reference:
https://github.com/webcomponents/polyfills/tree/master/packages/webcomponentsjs
It seems that there are some users using old browsers, so the
`window.customElements` need polyfill.
The Custom Elements would help a lot for Gitea's UI problems, including:
* `<span class="js-pretty-number">`
* `<time data-format>`
So it's worth get polyfill.
---------
Co-authored-by: delvh <dev.lh@web.de>
---
Hi, very naive and **untested** first time ever Go code, feel free to
reject/edit this as needed.
(PyPI actually performs "naive" string comparison too)
---------
Co-authored-by: Lauris BH <lauris@nix.lv>
When attempting to migrate a repository via the API endpoint comments
are always included. This can create a problem if your source repository
has issues or pull requests but you do not want to import them into
Gitea that displays as something like:
> Error 500: We were unable to perform the request due to server-side
problems. 'comment references non existent IssueIndex 4
There are only two ways to resolve this:
1. Migrate using the web interface
2. Migrate using the API including at issues or pull requests.
This PR matches the behavior of the API migration router to the web
migration router.
Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
1. The "close" inside "modal" are likely broken for long time
* There is no var called `--body-color`
* There is no `fullscreen modal`
* The `.ui.modal > .close.inside` doesn't seem to match most icons. It
only matches a few like "fork-repo-modal" or "adopt repo". Other places
are just buggy code copied again and again.
2. Convert the legacy `&:hover` LESS syntax to CSS syntax
`npm@8` which comes with node 16 will by default write lockfile v2
`npm@9` which comes with recent versions of node 18 and above will write
lockfile v3
To avoid incorrect lockfile v2 generation on npm v8, force npm to write
lockfile v3, so no matter which npm version the user has installed, the
same lockfile format will be generated.
References:
-
https://docs.npmjs.com/cli/v9/configuring-npm/package-lock-json#lockfileversion
- https://nodejs.org/en/download/releases
Co-authored-by: delvh <leon@kske.dev>
[`worker-loader`](https://github.com/webpack-contrib/worker-loader) is
deprecated since webpack 5 which can load workers without it now, so
remove it. I think it was already dysfunctional because the regex does
not match our current worker scripts:
```
web_src/js/features/eventsource.sharedworker.js
web_src/js/features/serviceworker.js
web_src/js/serviceworker.js
```
I did confirm that eventsource worker still loads via simple
`console.log` inside the script.
Co-authored-by: delvh <leon@kske.dev>
Close #23444
Add `Repository` to npm package `Metadata` struct so the `repository` in
`package.json` can be stored and be returned in the endpoint.
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
A part of https://github.com/go-gitea/gitea/pull/22865
At first, I think we do not need 3 ProjectTypes, as we can check user
type, but it seems that it is not database friendly.
---------
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: 6543 <6543@obermui.de>
