refactor: prepare to decouple the "model migration" package and "models" package (#38533)

Migrations should never use model structs directly, because the model
structs can be different in different releases. e.g. if one migration uses
"User" model, it works in the early releases, then one day, when the
User model changes, the migration breaks because it will use the
new (incorrect) User model, it should only use the old User model.

The same to "modules/structs".

---------

Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: delvh <dev.lh@web.de>

modelmigration/v1_27/v337.go

@@ -0,0 +1,36 @@
+// Copyright 2026 The Gitea Authors. All rights reserved.
+// SPDX-License-Identifier: MIT
+
+package v1_27
+
+import (
+	"gitea.dev/modelmigration/base"
+
+	"xorm.io/xorm"
+)
+
+type VisibleType int
+
+type teamWithVisibility struct {
+	Visibility VisibleType `xorm:"NOT NULL DEFAULT 2"`
+}
+
+func (teamWithVisibility) TableName() string {
+	return "team"
+}
+
+func AddVisibilityToTeam(x base.EngineMigration) error {
+	if _, err := x.SyncWithOptions(xorm.SyncOptions{
+		IgnoreDropIndices: true,
+		IgnoreConstrains:  true,
+	}, new(teamWithVisibility)); err != nil {
+		return err
+	}
+
+	// Owner teams must remain listable to all org members; new orgs create
+	// them as "limited", so make existing owner teams limited too.
+	// Filter on authorize=4 (AccessModeOwner) so a user-created team that
+	// happens to share the name "owners" is not accidentally affected.
+	_, err := x.Exec("UPDATE `team` SET visibility = ? WHERE lower_name = ? AND authorize = ?", 1, "owners", 4)
+	return err
+}