Allow team names of length 36 to accommodate UUIDs

[tobiasbp]

Feature Description

When integrating Gitea with other systems, I have the need to create organization teams the correspond to an external resource. As there is no way to tag a team, I would like to name the with a UUID that matches the UUID of my external resource. Users will never see the team names, so there are no UI issues with users wondering about the UUID names for teams.

Currently, the maximum length of a team name is 30 characters. I would like to have that changed to 36, which is the length of a UUID (32 hex characters and 4 hyphens).

I'm happy to make a PR with the change, if someone could point to the current definition in the code. I am unable to find it.

Screenshots

[KN4CK3R]

We could/should increase the length even more.

[silverwind]

What is the maximum team length name on GitHub/GitLab?

[KN4CK3R]

Looks like they don't have a limit. These are 200 a:

[philippbeckmann]

This collection implies the max length on GitHub is 255: https://github.com/dead-claudia/github-limits

[delvh]

I'm fine with anything below 255, so if there's a PR to change it, I'll approve it.

[silverwind]

I'm fine with anything below 255, so if there's a PR to change it, I'll approve it.

you likely meant "at or below" 😛

[tobiasbp]

Where in the code should the change be made?

[delvh]

modules/structs/org_team.go
27:     Name                    string `json:"name" binding:"Required;AlphaDashDot;MaxSize(30)"`
43:     Name                    string  `json:"name" binding:"AlphaDashDot;MaxSize(30)"`

I just had a look at the data model (/models/organization/team.go#79), and it looks like that already supports chars up to length 255.
So no need to change anything else

[silverwind]

I assume xorm would auto-migrate the column to the new size, right? If yes, then it is just a change in those structs that is ideally accompanied by a small test that creates a team at the new maximum length.

[techknowlogick]

@silverwind we require a migration for struct changes that would affect the DB, because even though automigrations will happen, we've run into cases in the past with too large of a version jump in the migration, then some auto-assumed migrations would be skipped (I haven't looked at this specific case though if it'd need the migration/struct change, but from above it seems it is just the validation that needs to be updated).

[delvh]

I assume xorm would auto-migrate the column to the new size, right

As I said, not needed, it's already varchar 255

[tobiasbp]

So, is the only thing needed then to change these values to 255?

modules/structs/org_team.go
27:     Name                    string `json:"name" binding:"Required;AlphaDashDot;MaxSize(30)"`
43:     Name                    string  `json:"name" binding:"AlphaDashDot;MaxSize(30)"`

[techknowlogick]

@tobiasbp yes, although I'd suggest making the change locally, compiling, and testing to see if the names can then handle the additional length (in case we are missing another validation area).
I would recommend against bumping the length all the way up to 255 as some filesystems don't like really long paths.

[delvh]

So, let's say 63?