5 Commits (7985cde84df5ee93bfb37b20681d69e67d3f32fc)

Author	SHA1	Message	Date
wxiaoguang	75c62054a6	Improve some modal action buttons (#24289) ... Follow #24097 and #24285 And add a devtest page for modal action button testing. http://localhost:3000/devtest/fomantic-modal Now the `modal_actions_confirm.tmpl` could support: green / blue / yellow positive buttons, the negative button is "secondary". ps: this PR is only a small improvement, there are still a lot of buttons not having proper colors. In the future these buttons could be improved by this approach. These buttons could also be improved according to the conclusion of #24285 in the future.  And add GitHub-like single danger button (context: https://github.com/go-gitea/gitea/issues/24285#issuecomment-1519100312)  --------- Co-authored-by: silverwind <me@silverwind.io>	2 years ago
Hester Gong	476a043a5f	Refactor delete_modal_actions template and use it for project column related actions (#24097) ... Co-Author: @wxiaoguang This PR is to fix https://github.com/go-gitea/gitea/issues/23318#issuecomment-1506275446 . The way to fix this in this PR is to use `delete_modal_actions.tmpl` here both to fix this issue and keep ui consistency (as suggested by [TODO here](4299c3b7db/templates/projects/view.tmpl (L161))) And this PR also refactors `delete_modal_actions.tmpl` and its related styles, and use the template for more modal actions: 1. Added template attributes: * locale * ModalButtonStyle: "yes" (default) or "confirm" * ModalButtonCancelText * ModalButtonOkText 2. Rename `delete_modal_actions.tmpl` template to `modal_actions_confirm.tmpl` because it is not only used for action modals deletion now. 3. Refactored css related to modals into `web_src/css/modules/modal.css` and improved the styles. 4. Also use the template for PR deletion modal and remove issue dependency modal. 5. Some modals should also use the template, but not sure how to open them, so mark these modal actions by `{{/* TODO: Convert to base/modal_actions_confirm */}}` After (Also tested on arc green): Hovering on the left buttons <img width="711" alt="Screen Shot 2023-04-23 at 15 17 12" src="https://user-images.githubusercontent.com/17645053/233825650-76307e65-9255-44bb-80e8-7062f58ead1b.png"> <img width="786" alt="Screen Shot 2023-04-23 at 15 17 21" src="https://user-images.githubusercontent.com/17645053/233825652-4dc6f7d1-a180-49fb-a468-d60950eaee0d.png"> Test for functionalities: https://user-images.githubusercontent.com/17645053/233826857-76376fda-022c-42d0-b0f3-339c17ca4e59.mov --------- Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>	2 years ago
zeripath	51383ec084	Move helpers to be prefixed with `gt-` (#22879) ... As discussed in #22847 the helpers in helpers.less need to have a separate prefix as they are causing conflicts with fomantic styles This will allow us to have the `.gt-hidden { display:none !important; }` style that is needed to for the reverted PR. Of note in doing this I have noticed that there was already a conflict with at least one chroma style which this PR now avoids. I've also added in the `gt-hidden` style that matches the tailwind one and switched the code that needed it to use that. Signed-off-by: Andrew Thornton <art27@cantab.net> --------- Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>	2 years ago
M Hickford	191a74d622	Record OAuth client type at registration (#21316) ... The OAuth spec [defines two types of client](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1), confidential and public. Previously Gitea assumed all clients to be confidential. > OAuth defines two client types, based on their ability to authenticate securely with the authorization server (i.e., ability to > maintain the confidentiality of their client credentials): > > confidential > Clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with > restricted access to the client credentials), or capable of secure client authentication using other means. > > **public > Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.** > > The client type designation is based on the authorization server's definition of secure authentication and its acceptable exposure levels of client credentials. The authorization server SHOULD NOT make assumptions about the client type. https://datatracker.ietf.org/doc/html/rfc8252#section-8.4 > Authorization servers MUST record the client type in the client registration details in order to identify and process requests accordingly. Require PKCE for public clients: https://datatracker.ietf.org/doc/html/rfc8252#section-8.1 > Authorization servers SHOULD reject authorization requests from native apps that don't use PKCE by returning an error message Fixes #21299 Co-authored-by: wxiaoguang <wxiaoguang@gmail.com> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>	2 years ago
qwerty287	a813c9d8f3	Allow creation of OAuth2 applications for orgs (#18084) ... Adds the settings pages to create OAuth2 apps also to the org settings and allows to create apps for orgs. Refactoring: the oauth2 related templates are shared for instance-wide/org/user, and the backend code uses `OAuth2CommonHandlers` to share code for instance-wide/org/user. Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>	2 years ago