- add a new button to the org view that is only shown to the org members
- add integration test to verify the expected navigatability
- add a new translation string to that button
- fix display style of "View <orgname>" button on the dashboard
- fix gap size between buttons on the org view by utilizing the common class top-right-buttons
- Similair to #2593 that removed subtle add button in a place where it's
strictly not needed.
- Remove the "Add organization" item in the 'context dashboard switcher' dropdown.
Fixes: https://github.com/go-gitea/gitea/issues/29981. Introduce
`.secondary-nav` as a universal way for styling and margin adjustments
inside `.page-content`.
If the first child of `.page-content` is `.secondary-nav`, we add margin
below it, otherwise we add padding to the first child. Notable changes:
- `--color-header-wrapper` is replaced with `--color-secondary-nav-bg`.
- `navbar` class is removed.
Co-authored-by: Giteabot <teabot@gitea.io>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
---
Conflict resolution: Trivial conflict & changed selector to reflect new
classes.
Ref: https://codeberg.org/forgejo/forgejo/issues/2776
(cherry picked from commit 3ccda41a539b8ba7841919ee12dc2877ddc03818)
Used all existing css vars, other migrations are 1:1.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit 34290a00c4501ffeba26db267be71ab68e3ec97f)
Conflicts:
templates/repo/issue/filter_list.tmpl
web_src/js/components/DashboardRepoList.vue
trivial context conflicts
Fix#26731
Almost all "tabindex" in code are incorrect.
1. All "input/button" by default are focusable, so no need to use "tabindex=0"
2. All "div/span" by default are not focusable, so no need to use "tabindex=-1"
3. All "dropdown" are focusable by framework, so no need to use "tabindex"
4. Some tabindex values are incorrect (eg: `new_form.tmpl`), so remove them
Co-authored-by: Giteabot <teabot@gitea.io>
To avoid duplicated load of the same data in an HTTP request, we can set
a context cache to do that. i.e. Some pages may load a user from a
database with the same id in different areas on the same page. But the
code is hidden in two different deep logic. How should we share the
user? As a result of this PR, now if both entry functions accept
`context.Context` as the first parameter and we just need to refactor
`GetUserByID` to reuse the user from the context cache. Then it will not
be loaded twice on an HTTP request.
But of course, sometimes we would like to reload an object from the
database, that's why `RemoveContextData` is also exposed.
The core context cache is here. It defines a new context
```go
type cacheContext struct {
ctx context.Context
data map[any]map[any]any
lock sync.RWMutex
}
var cacheContextKey = struct{}{}
func WithCacheContext(ctx context.Context) context.Context {
return context.WithValue(ctx, cacheContextKey, &cacheContext{
ctx: ctx,
data: make(map[any]map[any]any),
})
}
```
Then you can use the below 4 methods to read/write/del the data within
the same context.
```go
func GetContextData(ctx context.Context, tp, key any) any
func SetContextData(ctx context.Context, tp, key, value any)
func RemoveContextData(ctx context.Context, tp, key any)
func GetWithContextCache[T any](ctx context.Context, cacheGroupKey string, cacheTargetID any, f func() (T, error)) (T, error)
```
Then let's take a look at how `system.GetString` implement it.
```go
func GetSetting(ctx context.Context, key string) (string, error) {
return cache.GetWithContextCache(ctx, contextCacheKey, key, func() (string, error) {
return cache.GetString(genSettingCacheKey(key), func() (string, error) {
res, err := GetSettingNoCache(ctx, key)
if err != nil {
return "", err
}
return res.SettingValue, nil
})
})
}
```
First, it will check if context data include the setting object with the
key. If not, it will query from the global cache which may be memory or
a Redis cache. If not, it will get the object from the database. In the
end, if the object gets from the global cache or database, it will be
set into the context cache.
An object stored in the context cache will only be destroyed after the
context disappeared.
Same to https://github.com/go-gitea/gitea/pull/22674 and
https://github.com/go-gitea/gitea/pull/22605
Sorry to create 3 PR to fix this.
I checked all span with class `org-visibility`, i think this is the last
one :)
And I found that private/limited user has no private/limited tag in
dashboard. but org does.
If it is ok i will add this feature in another pr.
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Refactor `i18n` to `locale`
- Currently we're using the `i18n` variable naming for the `locale`
struct. This contains locale's specific information and cannot be used
for general i18n purpose, therefore refactoring it to `locale` makes
more sense.
- Ref: https://github.com/go-gitea/gitea/pull/20096#discussion_r906699200
* Update routers/install/install.go
* make blue really blue
* replace blue button and label classes with primary
* add --color-blue-dark
* add light color variants, tweak a few colors
* fix colors
* add comment
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
- `.Teams` isn't a field on the User type, thus using the seperate
loaded teams.
- Add a space between `PathEscape` and argument.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
There are multiple places where Gitea does not properly escape URLs that it is building and there are multiple places where it builds urls when there is already a simpler function available to use this.
This is an extensive PR attempting to fix these issues.
1. The first commit in this PR looks through all href, src and links in the Gitea codebase and has attempted to catch all the places where there is potentially incomplete escaping.
2. Whilst doing this we will prefer to use functions that create URLs over recreating them by hand.
3. All uses of strings should be directly escaped - even if they are not currently expected to contain escaping characters. The main benefit to doing this will be that we can consider relaxing the constraints on user names and reponames in future.
4. The next commit looks at escaping in the wiki and re-considers the urls that are used there. Using the improved escaping here wiki files containing '/'. (This implementation will currently still place all of the wiki files the root directory of the repo but this would not be difficult to change.)
5. The title generation in feeds is now properly escaped.
6. EscapePound is no longer needed - urls should be PathEscaped / QueryEscaped as necessary but then re-escaped with Escape when creating html with locales Signed-off-by: Andrew Thornton <art27@cantab.net>
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Fix truncated organization names
Previous ellipsis implementation hid vertical overflow - image + descent line of letters.
Organization visibility in select on dashboard was not always visible.
This commit extracts classes which don't make collisions with other items on page.
This applias the same checks from base/head_navbar.tmpl to user/dashboard/navbar.tmpl so no links are shown for globally disabled repo units
Co-authored-by: 6543 <6543@obermui.de>
In the "View [organization]" button on the dashboard, the organization name is currenly shortened to 10 chars.
This is a bit too limited. In all other places in the code the name is also shortened to 20 instead of 10.
Co-authored-by: 6543 <6543@obermui.de>
* Direct avatar rendering
This adds new template helpers for avatar rendering which output image
elements with direct links to avatars which makes them cacheable by the
browsers.
This should be a major performance improvment for pages with many avatars.
* fix avatars of other user's profile pages
* fix top border on user avatar name
* uncircle avatars
* remove old incomplete avatar selector
* use title attribute for name and add it back on blame
* minor refactor
* tweak comments
* fix url path join and adjust test to new result
* dedupe functions
* add explicit dimensions to navbar avatar
this prevents a temporary layout change when navigating between
pages with cache disabled.
* also add dimensions on frontpage
Co-authored-by: Lauris BH <lauris@nix.lv>
* UI: Make dashboard navbar full-width
* more tweaks: full-width footer and consistent padding
* fix page layout causing unneccesary scrollbars on small pages
* Viewport meta tag
* responsive: dashboard
* responsive: issues page
* responsive: Explore page
* responsive: navbar, and some navbar css refactoring
* responsive: button for collapsing navbar in mobile view
* Mark the hamburger button as active when pressed
* better homepage for responsive views
* Bring back jump class in navbar
The class was necessary, because this way the
dropdown doesn't assume the contents of the
selected item.
* make repository homes responsive
* Make file view page responsive
* Make forms look good on responsive views
* make commits and commit diff view responsive
* issues and PRs
* responsive wiki
* Don't place auto-init far off the page
* Minor changes to amend broken stuff
minor improvements
- make login/sign up in navbar stackable
- make navbar in explore and sign in not stackable
Change selected class in TestPullCompare
Fix typo that happened when rebasing
fix dashboard on org view
improve profile UI
Use clearing on file diff to fix broken UI caused by floating elements
remove unresolved merge conflict, and | Sanitize
Fix repo home not loading
