Remove unused CSRF options, decouple "new csrf protector" and "prepare"
logic, do not redirect to home page if CSRF validation falis (it
shouldn't happen in daily usage, if it happens, redirecting to home
doesn't help either but just makes the problem more complex for "fetch")
(cherry picked from commit 1fede04b83288d8a91304a83b7601699bb5cba04)
Conflicts:
options/locale/locale_en-US.ini
tests/integration/repo_branch_test.go
trivial context conflicts
Change word order for issue comment actions
- An attempt to address https://codeberg.org/forgejo/forgejo/issues/2650
Org team permissions improvements
- consistency: added missing dot
- clarity: explain what external units mean
- use dedicated keys to explain the permissions.
- split in read/write permissions
- use explicit labels for accessibility
- ext_wiki.desc and ext_issues.desc are no longer in use.
This is a followup to gitea#31973, and removes the HTML tags for the
rest of the languages too.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Part of #27700
Removes all URLs from translation strings to easy up changing them in
the future and to exclude people injecting malicious URLs through
translations. First measure as long as #24402 is out of scope.
(cherry picked from commit 83f37f630246e381eefd650fc2d4b1f3976ea882)
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Conflicts:
- options/locale/locale_en-US.ini
Resolved by manually applying the URL->%s changes to our translations.
- routers/web/admin/hooks.go
templates/repo/settings/protected_branch.tmpl
templates/status/500.tmpl
Manually resolved.
- templates/repo/settings/webhook/settings.tmpl
Applied the change to templates/webhook/shared-settings.tmpl
instead
Additional changes: Gitea-specific URLs have been replaced by their
Forgejo counterparts, lifted from the original translation text.
Follow #31950 and Fix the display bug of #31966 .
This will only fix the English version. I will update all these
translation files in crowdin after this merged so that all the languages
can be fixed.
And all these files should be backported together.
This PR remove the bold effect around the name when creating a new tag
or branch.
(cherry picked from commit a366af4b7a067227386184067e203091923b5b10)
- Follow up of #4819
- When no `ssh` executable is present, disable the UI and backend bits
that allow the creation of push mirrors that use SSH authentication. As
this feature requires the usage of the `ssh` binary.
- Integration test added.
- adds a header to indicate creating a new rule
- test that header is different between new and edit form
- consistently avoids colons in the form
- excludes some accessibility checks that require a global solution for
forms
- Continuation of https://github.com/go-gitea/gitea/pull/18835 (by
@Gusted, so it's fine to change copyright holder to Forgejo).
- Add the option to use SSH for push mirrors, this would allow for the
deploy keys feature to be used and not require tokens to be used which
cannot be limited to a specific repository. The private key is stored
encrypted (via the `keying` module) on the database and NEVER given to
the user, to avoid accidental exposure and misuse.
- CAVEAT: This does require the `ssh` binary to be present, which may
not be available in containerized environments, this could be solved by
adding a SSH client into forgejo itself and use the forgejo binary as
SSH command, but should be done in another PR.
- CAVEAT: Mirroring of LFS content is not supported, this would require
the previous stated problem to be solved due to LFS authentication (an
attempt was made at forgejo/forgejo#2544).
- Integration test added.
- Resolves#4416
UX/Translation changes:
- new teams: remove redundant tooltips that don't add meaningful information
- move general information to table fieldset
- new teams: rename "general" to "custom" access for clarity
- new teams: show labels beside options on mobile
Accessibility:
- semantic form elements allow easier navigation (fieldset, mostly)
- improve better labelling of new teams table
- fix accessibility scan issues
- TODO: the parts that "disable" form elements were not yet touched and
are not really accessible to screenreaders
Technical:
- replace two JavaScript solutions with one CSS standard
- implement a simpler grid (.simple-grid)
- simplify markup
- remove some webhook settings specific CSS
Testing:
- check more form content for accessibility issues
- but exclude tooltips from the scan :(
- reuse existing form tests from previous PR
---
Conflict resolution: trivial
Things done differently: Improve localization message, use the paragraph
element instead of the div element, fix passing this variable to the
template and add a integration test
(cherry picked from commit 9633f336c87947dc7d2a5e76077a10699ba5e50d)
- Adjust the counting of the number of lines of a file to match the
amount of rendered lines. This simply means that a file with the content
of `a\n` will be shown as having `1 line` rather than `2 lines`. This
matches with the amount of lines that are being rendered (the last empty
line is never rendered) and matches more with the expecation of the
user (a trailing EOL is a technical detail).
- In the case there's no EOL, the reason why it was counting
'incorrectly' was to show if there was a trailing EOL or not, but now
text is shown to tell the user this.
- Integration test added.
- ResolvesCodeberg/Community#1612
Part of #24256.
Clear up old action logs to free up storage space.
Users will see a message indicating that the log has been cleared if
they view old tasks.
<img width="1361" alt="image"
src="https://github.com/user-attachments/assets/9f0f3a3a-bc5a-402f-90ca-49282d196c22">
Docs: https://gitea.com/gitea/docs/pulls/40
---------
Co-authored-by: silverwind <me@silverwind.io>
(cherry picked from commit 687c1182482ad9443a5911c068b317a91c91d586)
Conflicts:
custom/conf/app.example.ini
routers/web/repo/actions/view.go
trivial context conflict
The previous commit laid out the foundation of the quota engine, this
one builds on top of it, and implements the actual enforcement.
Enforcement happens at the route decoration level, whenever possible. In
case of the API, when over quota, a 413 error is returned, with an
appropriate JSON payload. In case of web routes, a 413 HTML page is
rendered with similar information.
This implementation is for a **soft quota**: quota usage is checked
before an operation is to be performed, and the operation is *only*
denied if the user is already over quota. This makes it possible to go
over quota, but has the significant advantage of being practically
implementable within the current Forgejo architecture.
The goal of enforcement is to deny actions that can make the user go
over quota, and allow the rest. As such, deleting things should - in
almost all cases - be possible. A prime exemption is deleting files via
the web ui: that creates a new commit, which in turn increases repo
size, thus, is denied if the user is over quota.
Limitations
-----------
Because we generally work at a route decorator level, and rarely
look *into* the operation itself, `size:repos:public` and
`size:repos:private` are not enforced at this level, the engine enforces
against `size:repos:all`. This will be improved in the future.
AGit does not play very well with this system, because AGit PRs count
toward the repo they're opened against, while in the GitHub-style fork +
pull model, it counts against the fork. This too, can be improved in the
future.
There's very little done on the UI side to guard against going over
quota. What this patch implements, is enforcement, not prevention. The
UI will still let you *try* operations that *will* result in a denial.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Just a small PR fixing some lines.
* removed full stop from placeholders, they were placed inconsistent and it doesn't really makes sense to have them in placeholders. It's usually either no full stop or ellipsis.
* s/Issue labels/Labels - obviously labels aren't used just for issues
That's about it. I may or may not send other improvements for this page later, this is just a simple PR that doesn't need testing.
Preview: https://codeberg.org/attachments/f7040bb4-9749-4cd2-9953-289e1103ea3e
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4709
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
- In the spirit of #4635
- Notify the owner when their account is getting enrolled into TOTP. The
message is changed according if they have security keys or not.
- Integration test added.
- Currently if the password, primary mail, TOTP or security keys are
changed, no notification is made of that and makes compromising an
account a bit easier as it's essentially undetectable until the original
person tries to log in. Although other changes should be made as
well (re-authing before allowing a password change), this should go a
long way of improving the account security in Forgejo.
- Adds a mail notification for password and primary mail changes. For
the primary mail change, a mail notification is sent to the old primary
mail.
- Add a mail notification when TOTP or a security keys is removed, if no
other 2FA method is configured the mail will also contain that 2FA is
no longer needed to log into their account.
- `MakeEmailAddressPrimary` is refactored to the user service package,
as it now involves calling the mailer service.
- Unit tests added.
- Integration tests added.
* Closes https://codeberg.org/forgejo/forgejo/issues/4563
* A followup to my 2024-February investigation in the Localization room
* Restore Malayalam and Serbian locales that were deleted in 067b0c2664 and f91092453e. Bulgarian was also deleted, but we already have better Bulgarian translation.
* Remove ml-IN from the language selector. It was not usable for 1.5 years, has ~18% completion and was not maintained in those ~1.5 years. It could also have placeholder bugs due to refactors.
Restoring files gives the translators a base to work with and makes the project advertised on Weblate homepage for logged in users in the Suggestions tab. Unlike Gitea, we store our current translations directly in the repo and not on a separate platform, so it makes sense to add these files back.
Removing selector entry avoids bugs and user confusion. I will make a followup for the documentation.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4576
Reviewed-by: twenty-panda <twenty-panda@noreply.codeberg.org>
Resolves https://github.com/go-gitea/gitea/issues/26996
Added default sorting for milestones by name.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
---
Conflict resolution: trivial, was due to the improvement made to 'the due
date sorting' strings.
(cherry picked from commit e8d4b7a8b198eca3b0bd117efb422d7d7cac93fe)
- The usage of the `vue-bar-graph` is complicated, because of the `GSAP`
dependency they pull in, the dependency uses a non-free license.
- The code is rewritten to use the `chart.js` library, which is already
used to draw other charts in the activity tab. Due to the limitation of
`chart.js`, we have to create a plugin in order to have images as labels
and do click handling for those images.
- The chart isn't the same as the previous one, once again simply due to
how `chart.js` works, the amount of commits isn't drawn anymore in the
bar, you instead have to hover over it or look at the y-axis.
- Resolves#4569
Changes
* checkbox titles are no longer strong.
* added descriptions to all options. Mostly from memory, but there are a few sources:
- https://docs.gitea.com/help/faq#active-user-vs-login-prohibited-user
- https://docs.gitea.com/help/faq#restricted-users
* for git hooks, I just moved tooltip into description.
* renamed titles. The only important one is: "Disable sign-in" -> "Suspended account" as it has a change of terminology. We don't seem to have anything about this option in our docs though. This is what the option really does. In fact, it does not invalidate current sessions of the user, but shows them the same "Sign-in prohibited" screen for all actions.
Preview: https://codeberg.org/attachments/e5649045-dfe8-4327-869f-cb2530ca6b17
(the text of the last one is slightly outdated after review)
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4499
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
I changed the title of the registation email from "Welcome to Gitea" to
"Welcome to (appname)". I did this by substituting 'Gitea' in
register_notify to %s and formating the registration title in mail.go. I
changed this for all the languages I could, but I struggled to changed
the translation file for Farsi. I have attached the screenshots of
before and after and the related issue below.
Related issue:
https://github.com/go-gitea/gitea/issues/31108
Before change:
After:
---------
Signed-off-by: Sunny Wan <Sunnywan2020@gmail.com>
Co-authored-by: 6543 <6543@obermui.de>
(cherry picked from commit 4913edaa70a48f7c5a524f680ca921ed515d6ec2)
Conflicts:
- options/locale/locale_en-US.ini
Applied the change manually. Confliced because we don't have `register_notify.title`.
- services/mailer/mail.go
Adapted the change to Forgejo. We don't have `u.EmailTo` due to
not picking gitea#31527 (yet).
Add an empty hash `href="#"` attribute to anchors that did not yet have any `href` attribute, as a quick work-around to make those elements possible to interact with via keyboard. See discussion on linked issue (https://codeberg.org/forgejo/forgejo/issues/4273) for more information on how the button-like elements like this could eventually be improved even more.
Fixes https://codeberg.org/forgejo/forgejo/issues/4273.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4375
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: banaanihillo <banaanihillo@noreply.codeberg.org>
Co-committed-by: banaanihillo <banaanihillo@noreply.codeberg.org>
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>
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>
