- Currently if you want to update the milestone of an issue or pull
request, your whole page will be reloaded to reflect the newly set
milestone. This is quite unecessary, as only the milestone text is
updated and a new timeline event is added.
- This patch converts the milestone section in the issue/pull request
sidebar to use HTMX, so it becomes a progressive element and avoids
reloading the whole page to update the milestone.
- The update of the milestone section itself is quite straightforward
and nothing special is happening. To support adding new timeline events,
a new element `#insert-timeline` is conviently placed after the last
timeline event, which can be used with
[`hx-swap-oob`](https://htmx.org/attributes/hx-swap-oob/) to position
new timeline events before that element.
- Adds E2E test.
To reproduce:
- make the repo creation form return with an error, like a duplicate name
- click on the Object format dropdown
- the options are missing as the listbox is empty
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4360
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Solomon Victorino <git@solomonvictorino.com>
Co-committed-by: Solomon Victorino <git@solomonvictorino.com>
The `/repos/{owner}/{repo}/issues/comments/{id}` API endpoint returns an
`assets` field, but the route handler did not load attachments, thus,
the field was never populated.
This patch fixes that, and adds a test to exercise it. The test fails
without the fix.
This addresses a bug discovered in Codeberg/Community#1607.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
- We were previously using `github.com/keybase/go-crypto`, because the
package for openpgp by Go itself is deprecated and no longer
maintained. This library provided a maintained version of the openpgp
package. However, it hasn't seen any activity for the last five years,
and I would therefore consider this also unmaintained.
- This patch switches the package to `github.com/ProtonMail/go-crypto`
which provides a maintained version of the openpgp package and was
already being used in the tests.
- Adds unit tests, I've carefully checked the callstacks to ensure the
OpenPGP-related code was covered under either a unit test or integration
tests to avoid regression, as this can easily turn into security
vulnerabilities if a regression happens here.
- Small behavior update, revocations are now checked correctly instead
of checking if they merely exist and the expiry time of a subkey is used
if one is provided (this is just cosmetic and doesn't impact security).
- One more dependency eliminated :D
- Update the `github.com/santhosh-tekuri/jsonschema` library from v5 to
v6.
- Update the migration loader function to a type, which is now required
in V6.
- `github.com/santhosh-tekuri/jsonschema/v6` was already used by gof3,
so removing the v5 library and using the v6 library reduces the binary
size of Forgejo.
- Before: 95912040 bytes
- After: 95706152 bytes
- Don't show the labels-list element, if no labels are selected.
- The labels-list was taking up vertical space, even if no labels were
selected which caused an inconsistency in how the sidebar looked.
- Adds integration test
Fixes https://codeberg.org/forgejo/forgejo/issues/4417 by adding a conditional branch to the `head_opengraph` template to match wiki pages. I tried to be consistent with the other types:
- `og:title` is the wiki page title
- `og:url` is built via `{{AppUrl}}{{.Link}}` like it is done for commit and file views. This has the caveat of doubling the slash (see test below). Should we `{{trimSuffix "/" AppUrl}}` to remove this, if sprig is available?
- `og:description` is the repository description to match GH behaviour. Also, the first sentences of the page might not be descriptive enough. Should we prefix the repo description with the repo name?
- `og:type` and `og:image` are common
Added a `TestOpenGraphProperties` integration test using existing fixtures. Coverage is not 100% but can be improved later.
## Output on a test repo
```html
<meta property="og:title" content="Project architecture">
<meta property="og:url" content="http://localhost:3000//xvello/wiki-test/wiki/Project-architecture">
<meta property="og:description" content="description for a test project">
<meta property="og:type" content="object">
<meta property="og:image" content="http://localhost:3000/avatars/3dd4d1e4eef065d1b4ad4bdb081ab6e7">
```
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4427
Co-authored-by: Xavier Vello <xavier.vello@gmail.com>
Co-committed-by: Xavier Vello <xavier.vello@gmail.com>
I noticed that Forgejo does not allow HTTP range requests when downloading artifacts. All other file downloads like releases and packages support them.
So I looked at the code and found that the artifact download endpoint uses a simple io.Copy to serve the file contents instead of using the established `ServeContentByReadSeeker` function which does take range requests into account.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4218
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: ThetaDev <thetadev@magenta.de>
Co-committed-by: ThetaDev <thetadev@magenta.de>
If a repository has
git config --add push.pushOption submit=".sourcehut/*.yml"
it failed when pushed because of the unknown submit push
option. It will be ignored instead.
Filtering out the push options is done in an earlier stage, when the
hook command runs, before it submits the options map to the private
endpoint.
* move all the push options logic to modules/git/pushoptions
* add 100% test coverage for modules/git/pushoptions
Test coverage for the code paths from which code was moved to the
modules/git/pushoptions package:
* cmd/hook.go:runHookPreReceive
* routers/private/hook_pre_receive.go:validatePushOptions
tests/integration/git_push_test.go:TestOptionsGitPush runs through
both. The test verifying the option is rejected was removed and, if
added again, will fail because the option is now ignored instead of
being rejected.
* cmd/hook.go:runHookProcReceive
* services/agit/agit.go:ProcReceive
tests/integration/git_test.go: doCreateAgitFlowPull runs through
both. It uses variations of AGit related push options.
* cmd/hook.go:runHookPostReceive
* routers/private/hook_post_receive.go:HookPostReceive
tests/integration/git_test.go:doPushCreate called by TestGit/HTTP/sha1/PushCreate
runs through both.
Note that although it provides coverage for this code path it does not use push options.
Fixes: https://codeberg.org/forgejo/forgejo/issues/3651
We haven't decided much (to my knowledge), and I've been using the main branch in production (as one does) and found out even I myself rely on Tab sometimes working to move focus and have been caught off guard by it indenting lines instead.
So this removes Tab handling and instead adds two new buttons to the toolbar. The indentation logic is unchanged (other than now focusing the textarea during button handling, to ensure execCommand works, and thus undo history is preserved).
I'm not sure which terminology to use in tooltips. Could also add keyboard shortcuts for the whole toolbar eventually, but as is this is hopefully an better solution to the problems I previously created than un-merging the whole thing :)
<img width="414" alt="Screenshot with two new buttons" src="/attachments/b7af3aa4-a195-48d1-be0a-1559f25dce8e">
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4263
Reviewed-by: Otto <otto@codeberg.org>
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Danko Aleksejevs <danko@very.lv>
Co-committed-by: Danko Aleksejevs <danko@very.lv>
#3654 introduced support for searching non-default branches and tags.
However, the results page lacked any indicator (aside from the url) on which branch/tag the searcg was performed. A branch dropdown was introduced to the code search page when git-grep is used both as an indicator and as a intrusive way to switch between branches/tags.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4262
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Co-committed-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Closes#2797
I'm aware of https://github.com/go-gitea/gitea/pull/28163 exists, but since I had it laying around on my drive and collecting dust, I might as well open a PR for it if anyone wants the feature a bit sooner than waiting for upstream to release it or to be a forgejo "native" implementation.
This PR Contains:
- Support for the `workflow_dispatch` trigger
- Inputs: boolean, string, number, choice
Things still to be done:
- [x] API Endpoint `/api/v1/<org>/<repo>/actions/workflows/<workflow id>/dispatches`
- ~~Fixing some UI bugs I had no time figuring out, like why dropdown/choice inputs's menu's behave weirdly~~ Unrelated visual bug with dropdowns inside dropdowns
- [x] Fix bug where opening the branch selection submits the form
- [x] Limit on inputs to render/process
Things not in this PR:
- Inputs: environment (First need support for environments in forgejo)
Things needed to test this:
- A patch for https://code.forgejo.org/forgejo/runner to actually consider the inputs inside the workflow.
~~One possible patch can be seen here: https://code.forgejo.org/Mai-Lapyst/runner/src/branch/support-workflow-inputs~~
[PR](https://code.forgejo.org/forgejo/runner/pulls/199)
## Testing
- Checkout PR
- Setup new development runner with [this PR](https://code.forgejo.org/forgejo/runner/pulls/199)
- Create a repo with a workflow (see below)
- Go to the actions tab, select the workflow and see the notice as in the screenshot above
- Use the button + dropdown to run the workflow
- Try also running it via the api using the `` endpoint
- ...
- Profit!
<details>
<summary>Example workflow</summary>
```yaml
on:
workflow_dispatch:
inputs:
logLevel:
description: 'Log Level'
required: true
default: 'warning'
type: choice
options:
- info
- warning
- debug
tags:
description: 'Test scenario tags'
required: false
type: boolean
boolean_default_true:
description: 'Test scenario tags'
required: true
type: boolean
default: true
boolean_default_false:
description: 'Test scenario tags'
required: false
type: boolean
default: false
number1_default:
description: 'Number w. default'
default: '100'
type: number
number2:
description: 'Number w/o. default'
type: number
string1_default:
description: 'String w. default'
default: 'Hello world'
type: string
string2:
description: 'String w/o. default'
required: true
type: string
jobs:
test:
runs-on: docker
steps:
- uses: actions/checkout@v3
- run: whoami
- run: cat /etc/issue
- run: uname -a
- run: date
- run: echo ${{ inputs.logLevel }}
- run: echo ${{ inputs.tags }}
- env:
GITHUB_CONTEXT: ${{ toJson(github) }}
run: echo "$GITHUB_CONTEXT"
- run: echo "abc"
```
</details>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3334
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
Co-committed-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
There are a few changes of template logic which defines when which elements should be shown on profile page. The motivation is to have the elements when needed and don't when they're not relevant.
## Changes
### RSS button
Now displayed if:
* feeds are enabled
AND one or more of:
* the current user is an admin
* the current user is viewing their profile
* the activity is publicly available
So, basically in cases when the .rss feed actually contains any events. Before this change this button was constantly shown and was giving an empty feed if it was unavailable.
### Public activity tab
The tab is displayed if:
* the current user is an admin
* the current user is viewing their profile
* the activity is publicly available
* the current tab is this exact tab, for example, in case it was accessed by adding `?tab=activity` to the URL, so that the UI is not broken w/o a highlighted tab
So, this tab is not displayed when it's not going to contain any information, but still can be accessed.
### Banner "This user has disabled the public visibility of the activity."
For admins:
* always show the big blue banner to warn that sharing a screenshot of this publicly is bad idea
For self:
* always display a little note about the current visibility status with a "Change" link
For others:
* only display a little note to explain why the activity is not shown
### Heatmap and activity feed
Elements are only displayed when relevant, instead of keeping empty leftovers, for easier testing. This template change is also covered by test. **Everything in this Changes section is covered by test unless I forgot something.**
## Preview
There's obviously too many states to screenshot, here are highlights:
_Warning admin for why they're seeing the information_
_Viewing self - private_
_Viewing self - public_
_Don't have access to the information_
_The tab is not shown when the activity can't be accessed_
_Can't access the RSS feed_
_Can access the RSS feed_
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4189
Reviewed-by: Otto <otto@codeberg.org>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| code.forgejo.org/f3/gof3/v3 | require | minor | `v3.3.1` -> `v3.4.0` |
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am" (UTC), Automerge - "before 4am" (UTC).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MDkuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQwOS4xIiwidGFyZ2V0QnJhbmNoIjoiZm9yZ2VqbyIsImxhYmVscyI6WyJkZXBlbmRlbmN5LXVwZ3JhZGUiXX0=-->
Co-authored-by: Twenty Panda <twenty-panda@posteo.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4196
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Renovate Bot <forgejo-renovate-action@forgejo.org>
Co-committed-by: Renovate Bot <forgejo-renovate-action@forgejo.org>
Ports fuzzy search for `/issues` and `/pulls` from gitea.
Adds fuzzy search for `/user/repo/issues` and `/user/repo/pulls`.
---
## Notes
### Port: [`gitea#be5be0ac81`](be5be0ac81)
- CONFLICT (content): Merge conflict in routers/web/user/home.go
Conflict resolved by
1. keeping both `PageIsOrgIssues` and the newly introduced `IsFuzzy`
2. using `pager.AddParam(ctx, "fuzzy", "IsFuzzy")` rather than `pager.AddParamString("fuzzy", fmt.Sprintf("%v", isFuzzy))`
- CONFLICT (content): Merge conflict in templates/user/dashboard/issues.tmpl
Conflict resolved by keeping the changes from #4096, and picking the `&fuzzy=${{.IsFuzzy}}` inclusion to all urls and `{{if .PageIsPulls}}...`
### Port: [`gitea#fede3cbada`](fede3cbada)
- CONFLICT (content): Merge conflict in templates/user/dashboard/issues.tmpl
Conflict resolved by keeping previous changes and picking the replacement of `{{if .PageIsPulls}}...` with `{{template "shared/search/combo_fuzzy"...` which contains the replacement of `explorer.go` to `explorer.go_to`
### Fixup commit
replaces `Iif` with `if` which was introduced in gitea#fede3cbada
### Feature commit
adds in support for /user/repo/(issues|pulls) + test
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Kerwin Bryant <kerwin612@qq.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4160
Reviewed-by: twenty-panda <twenty-panda@noreply.codeberg.org>
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Co-committed-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
This adds org-mode readmes to the extensions that are prioritized when
searching for readme. Org-mode readmes come after markdown readmes in
terms of priority and before txt readmes.
Closes#4073
closes#3855
unlike #3854, this implementation uses a generic details html tag and a bit of tailwind magic...
---
## Maintainers Note
- previously tailwind classes of the form `[-a-zA-Z:0-9_.]` was disabled, however they were enabled since they were required for the `group-open:` classes
---
## Manual Testing
1. Visit the code search results after submitting a valid query for repo (if indexer disabled) or repo, user, explore (if indexer enabled)
2. Verify thst
1. the results are unfloded/open by default
2. the chevron points down when open and right when closed
<video src="/attachments/5a55c56f-6159-4422-ab80-962e0121e7d2" title="fold2.mp4" controls></video>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4134
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@noreply.codeberg.org>
Co-authored-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Co-committed-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
This overrides handling of Tab and Enter keys in the ComboMarkdownEditor, so that:
* Pressing Tab prepending 4 spaces to the line under cursor, or all the lines in the selection.
* Pressing Shift+Tab removes up to 4 spaces.
* Pressing Enter repeats any indentation and a "repeatable" prefix (list or blockquote) from the current line.
Since Tab "capture" can interfere with keyboard navigation, it's only done if there was any previous input in the textarea or if it was selected with a pointer. Additionally, presing Esc will make the textarea lose focus, resuming tab navigation. This seems adequate to me, but I might be wrong.
Had to use the "deprecated" execCommand method, since anything else I tried messes up the undo history. There's a fallback for when (if?) it's actually removed.
Only tested in desktop Firefox and Chrome so far.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4072
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@noreply.codeberg.org>
Co-authored-by: Danko Aleksejevs <danko@very.lv>
Co-committed-by: Danko Aleksejevs <danko@very.lv>
When a comment was added and saved with the preview tab active, the
preview tab is still active, when the comment is edited again.
This adds a "hacky" solution, but it works and is simple.
Every time the edit is "started" and the editor already exists, the tab
with the edit text field gets clicked to activate it.
Fixes#1334
* disabled the button itself, but added the tooltip to the form, because it didn't work for the button and likely has something to do with JS
* added an integration test to verify the new logic
## Preview
|Signed in|Guest|
|-|-|
|||
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4095
Reviewed-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
