Do not store user projects as organization projects

[yp05327]

A part of #22865

At first, I think we do not need 3 ProjectTypes, as we can check user type, but it seems that it is not database friendly.

[lunny]

And should we correct the error history types?

[lunny]

Or we can merge the two types as one. Because there is no difference between them.

[yp05327]

Or we can merge the two types as one. Because there is no difference between them.

If we merge the two types as one, when we want to check org/individual project type, we need to call LoadOwner which will call a db request. So maybe three types is better?

(Edited) Is there a better way to check org/individual project type?

[delvh]

We can store the type of project inside the db when creating it?
0 - repo project,
1 - org project,
(2 - user project, if it is ever supported)

As there is no convert this repo project to an org project, there isn't even anything to keep in mind…

[yp05327]

We already store the type of project inside the db when creating it.

We have three project types in current design:

gitea/models/project/project.go

Lines 38 to 47 in 608a3ee

	const (
	// TypeIndividual is a type of project board that is owned by an individual
	TypeIndividual Type = iota + 1
	// TypeRepository is a project that is tied to a repository
	TypeRepository
	// TypeOrganization is a project that is tied to an organisation
	TypeOrganization
	)

But when creating projects, we store TypeOrganization to both Individual and Organization Projects. This PR will fix this problem.

But before simply using TypeIndividual when creating individual projects,
As Individual and Organization are both User, why we don't merge TypeIndividual and TypeOrganization into TypeUser

gitea/models/user/user.go

Lines 38 to 44 in 2dc4f80

	const (
	// UserTypeIndividual defines an individual user
	UserTypeIndividual UserType = iota // Historic reason to make it starts at 0.
	// UserTypeOrganization defines an organization
	UserTypeOrganization
	)

At first, I think TypeUser is better because there is no difference between them, as lunny said.
But when we want to check whether a project is an Individual or Organization project, we need to LoadOwner, and then we can use project.Owner.IsOrganization() or project.Owner.IsIndividual().
This idea will call a db search, which is unnecessary I think, as if we use 3 project types, we can directly check project.Type==TypeOrganization or project.Type==TypeIndividual

I think this problem is a bit similar to #23038 (comment)
When there are a lot of projects in one page, holding the old design can reduce the calling of LoadOwner

After we decided to use which design, I will add a db migration to fix the error history types.

[lunny]

I don't against this solution. But we need to consider the migration.

[lunny]

CI failure is related.

[yp05327]

I found 2 problems, when using xorm:

• The order of variables in struct will effect the result

User struct

Correct Results:

Incorrect Results:

• Cant not find User.Type when use Update

When use Find, it works

When use Update, it does't work

You can check the code used in 5bcc68c

@lunny
Is this XORM's bugs or my code is bad?

[lunny]

Since there is a migration in this PR, it will not easy to backport the migration. But other code could be backport.

[yp05327]

#22235 added new column OwnerID to Project but have no migrations.
So the migration test failed in thie PR.

• Fix missed migration in #22235 #23482
  Must wait, until this PR is merged.

[delvh]

Does the unknown column error still happen?
If no, please add the wait-merge label

[yp05327]

Does the unknown column error still happen?

unknown column is fixed in #23482

[GiteaBot]

I was unable to create a backport for 1.19, please send one manually. 🍵

[wxiaoguang]

There is a DB migration, IMO it's impossible to be backported.