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?

[silverwind]

@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.

255 is fine for all common file systems: https://github.com/sindresorhus/valid-filename/blob/main/index.js

[techknowlogick]

@silverwind the folder length is not enough to look at, some FS (in mobile so I can't link) look at the full path as well. I want to say it's exFAT, but it might be another (common one).
I ran into it on my synology, and iirc that's using some btrfs derivative (caveat, I was using an encrypted drive which added additional constraints)

[silverwind]

@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.

255 is fine for all common file systems: https://github.com/sindresorhus/valid-filename/blob/main/index.js

Thought Windows does have a restriction called MAX_PATH that limits the full path length to 260 chars. I don't think team names can end up as filenames but for stuff that can (org name, repo name), I think 64 is a good limit.

[tobiasbp]

So... What do we want?

• 👍 63
• ❤️ 127
• 🎉 255

[KN4CK3R]

Maoam and 255.

[silverwind]

255, to match GitHub and because team names will likely never represent in the file system so things like MAX_PATH are not an issue.

[techknowlogick]

Ah, sorry, yes, my bad. I was thinking org name, even though you all have been saying team name this entire time. Please ignore my previous concerns. 255 is definitely a good choice for team name.

[silverwind]

Repo and org name limitations need to be investigated separately, I posted some regexes in #4150 (comment), but there is also a length limit.

[tobiasbp]

PR to change maximum length of team names to 255 characters: #31410

[techknowlogick]

closing due to merged PR