summaryrefslogtreecommitdiffstats
path: root/models/migrations/v1_22
Commit message (Collapse)AuthorAgeFilesLines
* Remove If Exist check on migration for mssql because that syntax required ↵Giteabot2024-05-122-10/+10
| | | | | | | | | | | | | | SQL server 2016 (#30894) (#30946) Backport #30894 by @lunny Fix #30872 We will assume the database is consistent before executing the migration. So the indexes should exist. Removing `IF EXIST` then is safe enough. Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: silverwind <me@silverwind.io>
* Rename migration package name for 1.22-rc1 (#30730)wxiaoguang2024-04-276-0/+166
| | | Ref: Propose to restart 1.22 release #30501
* Fix some bug on migrations (#30647)Lunny Xiao2024-04-241-1/+1
| | | Fix https://github.com/go-gitea/gitea/pull/23894#discussion_r1573718690
* Fix migration v292 (#30153)v1.22.0-rc0Lunny Xiao2024-03-283-83/+115
| | | | | | | | | | | | | Fix https://github.com/go-gitea/gitea/pull/29874#discussion_r1542227686 - The migration of v292 will miss many projects. These projects will have no default board. This PR introduced a new migration number and removed v292 migration. - This PR also added the missed transactions on project-related operations. - Only `SetDefaultBoard` will remove duplicated defaults but not in `GetDefaultBoard`
* Add default board to new projects, remove uncategorized pseudo-board (#29874)Denys Konovalov2024-03-272-0/+129
| | | | | | | | | | | | | | | | | | On creation of an empty project (no template) a default board will be created instead of falling back to the uneditable pseudo-board. Every project now has to have exactly one default boards. As a consequence, you cannot unset a board as default, instead you have to set another board as default. Existing projects will be modified using a cron job, additionally this check will run every midnight by default. Deleting the default board is not allowed, you have to set another board as default to do it. Fixes #29873 Fixes #14679 along the way Fixes #29853 Co-authored-by: delvh <dev.lh@web.de>
* Do some performance optimize for issues list and view issue/pull (#29515)Lunny Xiao2024-03-121-0/+14
| | | | | | | | | | | | | | This PR do some performance optimzations. - [x] Add `index` for the column `comment_id` of `Attachment` table to accelerate query from the database. - [x] Remove unnecessary database queries when viewing issues. Before some conditions which id = 0 will be sent to the database - [x] Remove duplicated load posters - [x] Batch loading attachements, isread of comments on viewing issue --------- Co-authored-by: Zettat123 <zettat123@gmail.com>
* Store webhook event in database (#29145)oliverpool2024-03-071-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refactor the webhook logic, to have the type-dependent processing happen only in one place. --- ## Current webhook flow 1. An event happens 2. It is pre-processed (depending on the webhook type) and its body is added to a task queue 3. When the task is processed, some more logic (depending on the webhook type as well) is applied to make an HTTP request This means that webhook-type dependant logic is needed in step 2 and 3. This is cumbersome and brittle to maintain. Updated webhook flow with this PR: 1. An event happens 2. It is stored as-is and added to a task queue 3. When the task is processed, the event is processed (depending on the webhook type) to make an HTTP request So the only webhook-type dependent logic happens in one place (step 3) which should be much more robust. ## Consequences of the refactor - the raw event must be stored in the hooktask (until now, the pre-processed body was stored) - to ensure that previous hooktasks are correctly sent, a `payload_version` is added (version 1: the body has already been pre-process / version 2: the body is the raw event) So future webhook additions will only have to deal with creating an http.Request based on the raw event (no need to adjust the code in multiple places, like currently). Moreover since this processing happens when fetching from the task queue, it ensures that the queuing of new events (upon a `git push` for instance) does not get slowed down by a slow webhook. As a concrete example, the PR #19307 for custom webhooks, should be substantially smaller: - no need to change `services/webhook/deliver.go` - minimal change in `services/webhook/webhook.go` (add the new webhook to the map) - no need to change all the individual webhook files (since with this refactor the `*webhook_model.Webhook` is provided as argument)
* Fix bug hidden on CI and make ci failed if tests failure (#29254)Lunny Xiao2024-03-074-18/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | The tests on migration tests failed but CI reports successfully https://github.com/go-gitea/gitea/actions/runs/7364373807/job/20044685969#step:8:141 This PR will fix the bug on migration v283 and also the CI hidden behaviour. The reason is on the Makefile `GITEA_ROOT="$(CURDIR)" GITEA_CONF=tests/mysql.ini $(GO) test $(GOTESTFLAGS) -tags='$(TEST_TAGS)' $(MIGRATE_TEST_PACKAGES)` will return the error exit code. But `for pkg in $(shell $(GO) list code.gitea.io/gitea/models/migrations/...); do \ GITEA_ROOT="$(CURDIR)" GITEA_CONF=tests/mysql.ini $(GO) test $(GOTESTFLAGS) -tags '$(TEST_TAGS)' $$pkg; \ done` will not work. This also fix #29602
* Make wiki default branch name changable (#29603)wxiaoguang2024-03-061-0/+18
| | | | | | | | | Fix #29000 Fix #28685 Fix #18568 Related: #27497 And by the way fix #24036, add a Cancel button there (one line)
* Add user blocking (#29028)KN4CK3R2024-03-041-0/+26
| | | | | | | | | | | | | | | | | | | | | | Fixes #17453 This PR adds the abbility to block a user from a personal account or organization to restrict how the blocked user can interact with the blocker. The docs explain what's the consequence of blocking a user. Screenshots: ![grafik](https://github.com/go-gitea/gitea/assets/1666336/4ed884f3-e06a-4862-afd3-3b8aa2488dc6) ![grafik](https://github.com/go-gitea/gitea/assets/1666336/ae6d4981-f252-4f50-a429-04f0f9f1cdf1) ![grafik](https://github.com/go-gitea/gitea/assets/1666336/ca153599-5b0f-4b4a-90fe-18bdfd6f0b6b) --------- Co-authored-by: Lauris BH <lauris@nix.lv>
* Add admin API route for managing user's badges (#23106)techknowlogick2024-03-012-0/+103
| | | | | | | Fix #22785 --------- Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Add support for sha256 repositories (#23894)Adam Majer2024-01-192-0/+166
| | | | | | | | | | | | | | | | Currently only SHA1 repositories are supported by Gitea. This adds support for alternate SHA256 with the additional aim of easier support for additional hash types in the future. Fixes: #13794 Limited by: https://github.com/go-git/go-git/issues/899 Depend on: #28138 <img width="776" alt="图片" src="https://github.com/go-gitea/gitea/assets/81045/5448c9a7-608e-4341-a149-5dd0069c9447"> --------- Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: 6543 <6543@obermui.de>
* Fix incorrect action duration time when rerun the job before executed once ↵yp053272024-01-191-0/+18
| | | | | | | | | | | | | | | | | | (#28364) Fix #28323 Reason was mentioned here: https://github.com/go-gitea/gitea/issues/28323#issuecomment-1841867298 ### Changes: (maybe breaking) We can rerun jobs in Gitea, so there will be some problems in calculating duration time. In this PR, I use the exist `Started` and `Stopped` column to record the last run time instead of the total time, and add a new `PreviousDuration` column to record the previous duration time. You can also check the cost time of last run: ![image](https://github.com/go-gitea/gitea/assets/18380374/2ca39145-2c92-401a-b78b-43164f7ae061)
* Add branch protection setting for ignoring stale approvals (#28498)Jimmy Praet2024-01-151-0/+14
| | | | | | | | | | | | | | | | | | | | | | Fixes #27114. * In Gitea 1.12 (#9532), a "dismiss stale approvals" branch protection setting was introduced, for ignoring stale reviews when verifying the approval count of a pull request. * In Gitea 1.14 (#12674), the "dismiss review" feature was added. * This caused confusion with users (#25858), as "dismiss" now means 2 different things. * In Gitea 1.20 (#25882), the behavior of the "dismiss stale approvals" branch protection was modified to actually dismiss the stale review. For some users this new behavior of dismissing the stale reviews is not desirable. So this PR reintroduces the old behavior as a new "ignore stale approvals" branch protection setting. --------- Co-authored-by: delvh <dev.lh@web.de>
* Fix migration test (#28659)Lunny Xiao2023-12-301-9/+9
|
* Add combined index for issue_user.uid and issue_id (#28080)sebastian-sauer2023-12-143-0/+76
| | | | | | | | fixes #27877 --------- Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Add Index to pull_auto_merge.doer_id (#27811)JakobDev2023-10-301-0/+16
| | | | | | | | Reported at https://codeberg.org/forgejo/forgejo/issues/1677 This column is used by [deleteUser](https://github.com/go-gitea/gitea/blob/f089be91da44ee3e85fbe326a204c7c8a5df3d31/services/user/delete.go#L90). Note: This PR contains a Migration, so we can't backport it to 1.21.
* Enhanced auth token / remember me (#27606)KN4CK3R2023-10-141-0/+21
| | | | | | | | | | | | | | | | | Closes #27455 > The mechanism responsible for long-term authentication (the 'remember me' cookie) uses a weak construction technique. It will hash the user's hashed password and the rands value; it will then call the secure cookie code, which will encrypt the user's name with the computed hash. If one were able to dump the database, they could extract those two values to rebuild that cookie and impersonate a user. That vulnerability exists from the date the dump was obtained until a user changed their password. > > To fix this security issue, the cookie could be created and verified using a different technique such as the one explained at https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence#secure-remember-me-cookies. The PR removes the now obsolete setting `COOKIE_USERNAME`.
* Rename the default themes to gitea-light, gitea-dark, gitea-auto (#27419)silverwind2023-10-061-0/+29
Part of https://github.com/go-gitea/gitea/issues/27097: - `gitea` theme is renamed to `gitea-light` - `arc-green` theme is renamed to `gitea-dark` - `auto` theme is renamed to `gitea-auto` I put both themes in separate CSS files, removing all colors from the base CSS. Existing users will be migrated to the new theme names. The dark theme recolor will follow in a separate PR. ## :warning: BREAKING :warning: 1. If there are existing custom themes with the names `gitea-light` or `gitea-dark`, rename them before this upgrade and update the `theme` column in the `user` table for each affected user. 2. The theme in `<html>` has moved from `class="theme-name"` to `data-theme="name"`, existing customizations that depend on should be updated. --------- Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: Giteabot <teabot@gitea.io>
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-14 11:02:58 +0000