1. make it able to "force reload", then the previous pending request
won't block the new request
2. make it support `::group::`
3. add some TS types (but there are still many variables untyped, this
PR is large enough, the remaining types could be added in the future)
Redesign the time tracker side bar, and add "time estimate" support (in "1d 2m" format)
Closes#23112
---------
Co-authored-by: stuzer05 <stuzer05@gmail.com>
Co-authored-by: Yarden Shoham <hrsi88@gmail.com>
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Fix a regression caused by jQuery removal (`renderPreviewPanelContent`)
And simplify the file editor, it doesn't need to be that complex. And
remove jQuery code.
Fix#32700, regression of recent markup refactoring
And by the way, clarify many legacy problems:
1. Some "RenderXxx" functions do not really "render", they only call "post processors"
2. Merge "RenderEmoji | RenderCodeBlock", they are all for "simple issue title"
Optimize partial layout and styling to achieve uniformity and
consistency.
Some buttons's structure is `<a><span><svg/></span></a>`, while others
buttons's structure is `<a><svg/></a>`. Additionally, some buttons have
icons that are **14** in size, while others have icons that are **16**.
Now, the layout has been unified to structure `<a><svg/></a>`, and the
icon size for all buttons has been standardized to the default size of
**16**.
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Usually enterprise/organization users would like to only allow OAuth2
login.
This PR adds a new config option to disable the password-based login
form. It is a simple and clear approach and won't block the future
login-system refactoring works.
Fix a TODO in #24821
Replace #21851Close#7633 , close#13606
- Fixes a translation keystring misuse where the string 'open
milestones' is used in place of 'closed milestones'.
- De-duplicates the use of 'open milesones' and 'closed milestones'
keystrings on the sidebar of an issue, reusing the ones on the issues
filter and action bars.
- Closes#32667
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Provide a cropping tool on the avatar editing page, allowing users to
select the cropping area themselves. This way, users can decide the
displayed area of the image, rather than us deciding for them.
---------
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: Giteabot <teabot@gitea.io>
## Solves
Currently for rules to re-order them you have to alter the creation
date. so you basicly have to delete and recreate them in the right
order. This is more than just inconvinient ...
## Solution
Add a new col for prioritization
## Demo WebUI Video
https://github.com/user-attachments/assets/92182a31-9705-4ac5-b6e3-9bb74108cbd1
---
*Sponsored by Kithara Software GmbH*
1. correct the modal usage on "admin email list" page (then
`web_src/js/features/admin/emails.ts` is removed)
2. use `addDelegatedEventListener` instead of `jQuery().on`
3. more jQuery related changes and remove jQuery from
`web_src/js/features/common-button.ts`
4. improve `confirmModal` to make it support header, and remove
incorrect double-escaping
5. fix more typescript related types
6. fine tune devtest pages and add more tests
Resolve#31609
This PR was initiated following my personal research to find the
lightest possible Single Sign-On solution for self-hosted setups. The
existing solutions often seemed too enterprise-oriented, involving many
moving parts and services, demanding significant resources while
promising planetary-scale capabilities. Others were adequate in
supporting basic OAuth2 flows but lacked proper user management
features, such as a change password UI.
Gitea hits the sweet spot for me, provided it supports more granular
access permissions for resources under users who accept the OAuth2
application.
This PR aims to introduce granularity in handling user resources as
nonintrusively and simply as possible. It allows third parties to inform
users about their intent to not ask for the full access and instead
request a specific, reduced scope. If the provided scopes are **only**
the typical ones for OIDC/OAuth2—`openid`, `profile`, `email`, and
`groups`—everything remains unchanged (currently full access to user's
resources). Additionally, this PR supports processing scopes already
introduced with [personal
tokens](https://docs.gitea.com/development/oauth2-provider#scopes) (e.g.
`read:user`, `write:issue`, `read:group`, `write:repository`...)
Personal tokens define scopes around specific resources: user info,
repositories, issues, packages, organizations, notifications,
miscellaneous, admin, and activitypub, with access delineated by read
and/or write permissions.
The initial case I wanted to address was to have Gitea act as an OAuth2
Identity Provider. To achieve that, with this PR, I would only add
`openid public-only` to provide access token to the third party to
authenticate the Gitea's user but no further access to the API and users
resources.
Another example: if a third party wanted to interact solely with Issues,
it would need to add `read:user` (for authorization) and
`read:issue`/`write:issue` to manage Issues.
My approach is based on my understanding of how scopes can be utilized,
supported by examples like [Sample Use Cases: Scopes and
Claims](https://auth0.com/docs/get-started/apis/scopes/sample-use-cases-scopes-and-claims)
on auth0.com.
I renamed `CheckOAuthAccessToken` to `GetOAuthAccessTokenScopeAndUserID`
so now it returns AccessTokenScope and user's ID. In the case of
additional scopes in `userIDFromToken` the default `all` would be
reduced to whatever was asked via those scopes. The main difference is
the opportunity to reduce the permissions from `all`, as is currently
the case, to what is provided by the additional scopes described above.
Screenshots:
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
