Some repos are missing in global and org code search #10434

New Issue

2025-11-02T09:07:18-06:00

GiteaMirror commented

2025-11-02 09:07:18 -06:00

Originally created by @silverwind on GitHub (Mar 14, 2023).

Description

I have one odd issue with code search where results from some repos do not show up in the global code search or the organization code search. The user is member of the default Owners team of two repos, let's call them org1/repo1 and org2/repo2.

Both repos are private
Both orgs are private
Both repos have the exact same settings in the UI
Both repos contain string query in one of their files

/org1/repo1/search?q=query shows results
/org2/repo2/search?q=query shows results
/org1/-/code?q=query shows results
/org2/-/code?q=query show NO results
/explore/code?q=query shows NO results from repo2, only from repo1

Giving the user admin permission fixes the issue
Adding the user to repo2 as collaborator fixes the issue
Switching repo2 to public access fixes the issue
Switching org2 to public access has no effect

There is probably still some difference in these repos in the database, but I'm not sure what to look at. Any pointers appreciated on what to look for.

Gitea Version

1.19.0+rc1-37-g0a0f46f29

Can you reproduce the bug on the Gitea demo site?

No

Database

MySQL

Originally created by @silverwind on GitHub (Mar 14, 2023). ### Description I have one odd issue with code search where results from some repos do not show up in the global code search or the organization code search. The user is member of the default `Owners` team of two repos, let's call them `org1/repo1` and `org2/repo2`. - Both repos are private - Both orgs are private - Both repos have the exact same settings in the UI - Both repos contain string `query` in one of their files `/org1/repo1/search?q=query` shows results `/org2/repo2/search?q=query` shows results `/org1/-/code?q=query` shows results `/org2/-/code?q=query` show NO results `/explore/code?q=query` shows NO results from `repo2`, only from `repo1` - Giving the user admin permission fixes the issue - Adding the user to `repo2` as collaborator fixes the issue - Switching `repo2` to public access fixes the issue - Switching `org2` to public access has no effect There is probably still some difference in these repos in the database, but I'm not sure what to look at. Any pointers appreciated on what to look for. ### Gitea Version 1.19.0+rc1-37-g0a0f46f29 ### Can you reproduce the bug on the Gitea demo site? No ### Database MySQL

GiteaMirror added the type/bug label 2025-11-02 09:07:18 -06:00

GiteaMirror closed this issue

2025-11-02 09:07:18 -06:00

GiteaMirror commented

2025-11-02 09:07:19 -06:00

@silverwind commented on GitHub (Mar 14, 2023):

I have narrowed it down to the following SQL query:

SELECT name from repository where id in (
  SELECT repo_id FROM team_repo
     INNER JOIN team_user ON `team_user`.team_id = `team_repo`.team_id
     INNER JOIN team_unit ON `team_unit`.team_id = `team_repo`.team_id
     WHERE `team_user`.uid=1234
       AND `team_unit`.`type`=1
       AND `team_unit`.`access_mode`>0
)

It seems the access_mode condition is the failing one, if I remove it, I get the missing repo to show up.

@silverwind commented on GitHub (Mar 14, 2023): I have narrowed it down to the following SQL query: ```sql SELECT name from repository where id in ( SELECT repo_id FROM team_repo INNER JOIN team_user ON `team_user`.team_id = `team_repo`.team_id INNER JOIN team_unit ON `team_unit`.team_id = `team_repo`.team_id WHERE `team_user`.uid=1234 AND `team_unit`.`type`=1 AND `team_unit`.`access_mode`>0 ) ``` It seems the `access_mode` condition is the failing one, if I remove it, I get the missing repo to show up.

GiteaMirror commented

2025-11-02 09:07:19 -06:00

@silverwind commented on GitHub (Mar 14, 2023):

I think the access_mode value of the Owners team is incorrect. It is 0 (no access) for some owner teams but should be 4 (full access), but as the owner team is not editable in the UI, I think this can only be remedied via SQL.

@silverwind commented on GitHub (Mar 14, 2023): I think the `access_mode` value of the Owners team is incorrect. It is 0 (no access) for some owner teams but should be 4 (full access), but as the owner team is not editable in the UI, I think this can only be remedied via SQL.

GiteaMirror commented

2025-11-02 09:07:19 -06:00

@silverwind commented on GitHub (Mar 14, 2023):

So I fixed the affected teams with this SQL:

update team_unit set access_mode = 4 where id in (
  select id from (
    select team_unit.id from team_unit
      inner join team on team_unit.team_id = team.id
      where name = "Owners" and team_unit.access_mode = 0
  ) as _
)

Creating a new org seems again create Owner teams with team_unit.access_mode=0, so I think there is a bug in current code that creates these "broken" teams. After creating a new org, I again see a broken Owners team was created with this query:

select distinct(team.id) from team_unit 
  inner join team on team_unit.team_id = team.id
  where name = "Owners" and team_unit.access_mode = 0;

@silverwind commented on GitHub (Mar 14, 2023): So I fixed the affected teams with this SQL: ```sql update team_unit set access_mode = 4 where id in ( select id from ( select team_unit.id from team_unit inner join team on team_unit.team_id = team.id where name = "Owners" and team_unit.access_mode = 0 ) as _ ) ``` Creating a new org seems again create Owner teams with `team_unit.access_mode=0`, so I think there is a bug in current code that creates these "broken" teams. After creating a new org, I again see a broken Owners team was created with this query: ```sql select distinct(team.id) from team_unit inner join team on team_unit.team_id = team.id where name = "Owners" and team_unit.access_mode = 0; ```

GiteaMirror commented

2025-11-02 09:07:19 -06:00

@silverwind commented on GitHub (Mar 14, 2023):

Reproduces locally as well. Just create a new org and check the access_mode of Owners via SQL:

localhost> select distinct(team.id) from team_unit inner join team on team_unit.team_id = team.id where name = "Owners" and team_unit.access_mode = 0;
+----+
| id |
+----+
|  4 |
+----+
1 row in set (0.001 sec)

@silverwind commented on GitHub (Mar 14, 2023): Reproduces locally as well. Just create a new org and check the `access_mode` of `Owners` via SQL: ``` localhost> select distinct(team.id) from team_unit inner join team on team_unit.team_id = team.id where name = "Owners" and team_unit.access_mode = 0; +----+ | id | +----+ | 4 | +----+ 1 row in set (0.001 sec) ```

GiteaMirror commented

2025-11-02 09:07:19 -06:00

@silverwind commented on GitHub (Apr 10, 2023):

Fixed by https://github.com/go-gitea/gitea/pull/23675

@silverwind commented on GitHub (Apr 10, 2023): Fixed by https://github.com/go-gitea/gitea/pull/23675

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#10434