These are some slight design changes to how usercards are presented.
- `margin`: removed one of the sides so the margins are the same in both axis
- `margin`: increased from 10px to 15px
Previously it was (Y, X) = (20, 10); now it's (15, 15)
- `width`: slightly decreased so that the point, where too small screen width causes card relocation to another row, doesn't increase
- `padding`: this change does nothing visually. `padding-bottom` was useless because padding was already set for all sides by another rule `.ui.segment {padding: 1em};`. This change just ensures that padding stays the same for all sides even if `.ui.segment` changes, instead of causing inconsistency
- `margin-bottom`: added as an override to margin caused by `display: flex`. From my research, usually there's `25px` gap between the content and the pagination. It was `39px` here, now it's `25px` too
### Before
### After
I can't show the distance between the content and the pagination, but the change does work when applying via devtools on https://codeberg.org/forgejo/forgejo/stars.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3915
Reviewed-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@noreply.codeberg.org>
Reviewed-by: Caesar Schinas <caesar@caesarschinas.com>
This PR ports [gitea#30858](https://github.com/go-gitea/gitea/pull/30858) / [this commit](5c236bd4c0) to forgejo.
[week 2024-20 cherry pick](https://codeberg.org/forgejo/forgejo/pulls/3729)
## Tests
- [ ] Click "edit" to get into edit mode, change the title and then use Alt+Enter to save the title
## Screenshots
Before:
After:
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3797
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
Co-committed-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
Fix#3638
This is a manual Forgejo-specific version of the Gitea PR https://github.com/go-gitea/gitea/pull/30862. The weekly Forgejo PR #3772 could not cherry-pick this commit due to conflicts (eg subsequent CodeSpell changes).
Only occurs with Webkit in Safari over eg `http://192..`. (not localhost).
See https://webkit.org/blog/10855/async-clipboard-api/
---
**Before**
**After**
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3805
Reviewed-by: Otto <otto@codeberg.org>
Co-authored-by: David Davies-Payne <d2p@me.com>
Co-committed-by: David Davies-Payne <d2p@me.com>
Enable
[`declaration-block-no-redundant-longhand-properties`](https://stylelint.io/user-guide/rules/declaration-block-no-redundant-longhand-properties/)
and autofix issues. The exclusions are because I find these two
shorthands to be harder to read.
(cherry picked from commit 46b7004f050bd2fdaf9800794cf2c1e9eeb08d51)
Signed-off-by: Beowulf <beowulf@beocode.eu>
Forbid
[deprecated](https://drafts.csswg.org/css-text-3/#word-break-property)
`break-word` and fix all occurences.
Regarding `overflow-wrap: break-word` vs `overflow-wrap: anywhere`:
Example of difference: https://jsfiddle.net/silverwind/1va6972r/
[Here](https://stackoverflow.com/questions/77651244) it says:
> The differences between normal, break-word and anywhere are only clear
if you are using width: min-content on the element containing the text,
and you also set a max-width. A pretty rare scenario.
I don't think this difference will make any practical impact as we are
not hitting this rare scenario.
(cherry picked from commit 5556782ebeb1ca4d17e2fff434b11651887b9899)
The previous implementation will start multiple POST requests from the
frontend when moving a column and another bug is moving the default
column will never be remembered in fact.
- [x] This PR will allow the default column to move to a non-first
position
- [x] And it also uses one request instead of multiple requests when
moving the columns
- [x] Use a star instead of a pin as the icon for setting the default
column action
- [x] Inserted new column will be append to the end
- [x] Fix#30701 the newly added issue will be append to the end of the
default column
- [x] Fix when deleting a column, all issues in it will be displayed
from UI but database records exist.
- [x] Add a limitation for columns in a project to 20. So the sorting
will not be overflow because it's int8.
---------
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit a303c973e0264dab45a787c4afa200e183e0d953)
Conflicts:
routers/web/web.go
e91733468ef726fc9365aa4820cdd5f2ddfdaa23 Add missing database transaction for new issue (#29490) was not cherry-picked
services/issue/issue.go
fe6792dff3 Enable/disable owner and repo projects independently (#28805) was not cherry-picked
Before this patch, we were using `Date` getter/setter methods that
worked with local time to get a list of Sundays that are in the range of
some start date and end date. The problem with this was that the Sundays
are in Unix epoch time and when we changed the "startDate" argument that
was passed to make sure it is on a Sunday, this change would be
reflected when we convert it to Unix epoch time. More specifically, I
observed that we may get different Unix epochs depending on your
timezone when the returned list should rather be timezone-agnostic.
This led to issues in US timezones that caused the contributor, code
frequency, and recent commit charts to not show any chart data. This fix
resolves this by using getter/setter methods that work with UTC since it
isn't dependent on timezones.
Fixes#30851.
---------
Co-authored-by: Sam Fisher <fisher@3echelon.local>
(cherry picked from commit 22c7b3a74459833b86783e84d4708c8934d34e58)
Regression of #29920Fixes: #30569
Also this is a rewriting to eliminate the remaining jQuery usages from code.
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit d0e07083559180b124a08359fcc72f9ef695e723)
Conflicts:
- web_src/js/features/repo-common.js
Conflict resolved in favour of Gitea.
More about codespell: https://github.com/codespell-project/codespell .
I personally introduced it to dozens if not hundreds of projects already and so far only positive feedback.
```
❯ grep lint-spell Makefile
@echo " - lint-spell lint spelling"
@echo " - lint-spell-fix lint spelling and fix issues"
lint: lint-frontend lint-backend lint-spell
lint-fix: lint-frontend-fix lint-backend-fix lint-spell-fix
.PHONY: lint-spell
lint-spell: lint-codespell
.PHONY: lint-spell-fix
lint-spell-fix: lint-codespell-fix
❯ git grep lint- -- .forgejo/
.forgejo/workflows/testing.yml: - run: make --always-make -j$(nproc) lint-backend checks-backend # ensure the "go-licenses" make target runs
.forgejo/workflows/testing.yml: - run: make lint-frontend
```
so how would you like me to invoke `lint-codespell` on CI? (without that would be IMHO very suboptimal and let typos sneak in)
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3270
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Yaroslav Halchenko <debian@onerussian.com>
Co-committed-by: Yaroslav Halchenko <debian@onerussian.com>
This fixes `initRepoPullRequestAllowMaintainerEdit()` to submit the form correctly (as a web form, rather than as JSON payload).
Fixes#3618, cherry picked from gitea#30854.
Co-Authored-By: wxiaoguang <wxiaoguang@gmail.com>
---
Manual testing steps:
- Open a PR against any repository, with the "Allow edits from maintainers" option checked.
- Open the developer console (`Ctrl-Shift-I` on Firefox), and look at the Network tab.
- Visit the PR, find the "Allow edits from maintainers" checkbox, and click it.
- See the developer console, and check that the response says the setting is false.
- Refresh the page *completely* (`Ctrl-Shift-R` on Firefox)
- Observe that the setting is off.
- Click the box again to enable it.
- See the developer console, and check that the response says the setting is true.
- Reload without cache again (`Ctrl-Shift-R` on Firefox)
- Observe that the setting is now on.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3675
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Co-committed-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Makes it easier to use because you see which square is currently
hovered:
<img width="314" alt="Screenshot 2024-05-02 at 15 38 20"
src="https://github.com/go-gitea/gitea/assets/115237/3a15dad1-2259-4f28-9fae-5cf6ad3d8798">
I did try a `scoped` style for this, but that did not work for some
reason.
(cherry picked from commit 6f89d5e3a0886d02ead732005f593ae003f78f78)
This is a very old bug with the bottom border-radiuses not being there
and the `:has` selector now makes it possible to cleanly solve it. It
affects all header+segment boxes, which there are many throughout the
UI:
<img width="1017" alt="Screenshot 2024-04-23 at 20 47 21"
src="https://github.com/go-gitea/gitea/assets/115237/870fe352-cc38-4bd6-bfe6-9fe8c3066f92">
(cherry picked from commit 3f19a6334575e1d2849999e8339f1b515cefaf1a)
- `.text-thin` and `.text-italic` are not present in CSS so were doing nothing and I removed them.
- `.text.middle` was unused so I removed it.
- `.text.italic` is replaced with `tw-italic`.
- `.text.normal` had exactly one use and it wasn't even needed.
- add a `muted` class to the link to `org_profile_avatar.tmpl`.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit aff7b7bdd285cc1fcabea774f153886e11ae9f5d)
This will move the settings button back to the right, like known from
older versions.
For this, the overflow-menu was changed when a setting button is
available. If no settings button is available, the behavior will not
change.
Fixes#3301
The WIP prefix toggling link on the sidebar only supported toggling
the *first* prefix specified in
`[repository.pullrequest].WORK_IN_PROGRESS_PREFIXES`. If the pull
request had a title with any other prefix, the first prefix listed in
the config was added (and then removed on toggling it off).
This little change makes all of the prefixes available for the
JavaScript function that does the toggling, and changes said function to
find the used prefix first, and toggle that.
When adding the prefix, it will still default to adding the first one
listed in the configuration, but it will happily remove any others if
those are present.
Fixes#3377.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Fixes: https://github.com/go-gitea/gitea/issues/30384
On repo settings page, there id `repo_name` was used 5 times on the same
page, some in modal and such. I think we are better off just
auto-generating these IDs in the future so that labels link up with
their form element.
Ideally this id generation would be done in backend in a subtemplate,
but seeing that we already have similar JS patches for checkboxes, I
took the easy path for now.
I also checked that these `#repo_name` were not in use in JS and the
only case where this id appears in JS is on the migration page where
it's still there.
---------
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit d4ec6b3d16496ce3b479d5a08f79823122dc2b7b)
Conflicts:
- templates/repo/settings/options.tmpl
Conflict resolved by manually removing all `id` and `for`
attributes from elements that had `repo_name` as their id.
