Don't require team membership for team search results

[noerw]

Another regression from #18518.

Note that tests for other routes expect non-team-members not to have access to it:

• gitea/tests/integration/api_team_test.go

  Line 42 in 4aafe26

  // non team member user will not access the teams details

• gitea/routers/web/org/teams.go

  Line 342 in 7922431

  // UserID is not set because the router already requires the doer to be an org admin. Thus, we don't need to restrict to teams that the user belongs in

But I'd argue this assumption breaks the quite valid use-case of searching for teams you are not a member of.
Also the /api/v1/orgs/{org}/teams endpoint (available to org members) will happily list all existing teams, so there is some inconsistency here already. I'd say you don't need to be team member to see details, as the information gained is not exactly sensitive.

related discussion for permissions in the frontend:

• Fix SQL Query for SearchTeam #20844
• Error (HTTP 404) When Assigning Teams to Repos #20658

[lunny]

CI failure is related.

[Gusted]

as the information gained is not exactly sensitive.

		apiTeams[i] = &api.Team{
			ID:                      teams[i].ID,
			Name:                    teams[i].Name,
			Description:             teams[i].Description,
			IncludesAllRepositories: teams[i].IncludesAllRepositories,
			CanCreateOrgRepo:        teams[i].CanCreateOrgRepo,
			Permission:              teams[i].AccessMode.String(),
			Units:                   teams[i].GetUnitNames(),
			UnitsMap:                teams[i].GetUnitsMap(),
		}

Which information is exactly needed, maybe we could limit it to just the necessary fields? I do find this to be quite "senstive" as it laids out the whole team structure in a organization.

[noerw]

Which information is exactly needed, maybe we could limit it to just the necessary fields?

I want to know which teams exist with what purpose, so I know what access to request. So .Name and .Description would be enough for the transparency & fast communication use case I have in mind.

I do find this to be quite "senstive" as it laids out the whole team structure in a organization.

Under what premise is this a bad thing? I can see it as a social engineering attack vector, but that's about it.
If you need to wall information off coworkers for some reason, gitea provides you with tools already: just create another private gitea org.

My main goal here is to make the API permissions consistent, I don't see a strictly better option.
Philosophically I strongly prefer to make existing teams visible to all org members (in the spirit of transparency, accountability, flat hierarchies, and short communication paths).
That said, this decision is of course not about my preferences, but should accommodate the needs of most gitea users. I'm arguing that gitea already provides tools to wall information off others (private orgs), so gitea would be enhanced by also enabling users that prefer less secrecy.

[Gusted]

I'm sorry @noerw for the late reaction, I'm pretty sure I was misunderstanding this code and situation. Limiting the return results to Name + Description is fine IMO.

[lunny]

replaced by #20844