Org name doesn't change after User is renamed

[zc-devs]

Component

server

Describe the bug

Local Gitea usr2 exists

woodpecker_test=# select user_id, user_login, user_org_id from users order by user_id;
 user_id | user_login | user_org_id
---------+------------+-------------
       3 | usr2       |           3
(5 rows)

woodpecker_test=# select * from orgs;
 id | name | is_user | private
----+------+---------+---------
  3 | usr2 | t       | f
(5 rows)

Go to Gitea Site Administration -> Identity and Access -> User Accounts. Edit usr2. Change Username to usr2-gitea-local.
Relogin in Gitea and Woodpecker by usr2-gitea-local.

woodpecker_test=# select user_id, user_login, user_org_id from users order by user_id;
 user_id |    user_login    | user_org_id
---------+------------------+-------------
       3 | usr2-gitea-local |           3
(5 rows)

woodpecker_test=# select * from orgs;
 id | name | is_user | private
----+------+---------+---------
  3 | usr2 | t       | f

User login was changed, but not organization name.
Now, if we go to User's profile page in Woodpecker we get

An unknown error occurred
GET
https://woodpecker.test.smthd.com/api/orgs/3/secrets?page=1
[HTTP/2 403  61ms]

System Info

Woodpecker 2.3.0, Gitea 1.21.5, Postgres 16

Additional context

No response

Validations

• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Checked that the bug isn't fixed in the next version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]

[zc-devs]

#3328 (comment)

users.user_login=MrMeeb
orgs.name=mrmeeb

@MrMeeb, try to rename user to mrmeeb or organization to MrMeeb and test again.

[MrMeeb]

Updated orgs.name to MrMeeb and now it seems to work. Want to be clear that I did not rename my user to cause this though, this was the out of the box behaviour. All I did was sign in to Woodpecker and try to create secrets.

[pat-s]

Hmm, looks like we do have a sanitization issue? Maybe this is also the solution for the cases in https://codeberg.org/Codeberg-CI/feedback/issues/149 where actually there is a valid, unique user org but the username is capitalized while in the org table it is all lowercase.

[pat-s]

Uff, we really have a case-sensitive DB issue: https://codeberg.org/Codeberg-CI/feedback/issues/149#issuecomment-1572908

[zc-devs]

case-sensitive DB issue

Should separate issue be opened?

[MrMeeb]

I'll add that when going to User > Secrets, the workaround resolves this. When going into a repo > secrets, I'm seeing a similar issue: accessing https://ci.domain.com/api/secrets?page=1 gets 403. Weirdly when going to the secrets tab of the repo I can see my organisation secrets, and create secrets in the repo. But I still get that 403 error

[qwerty287]

accessing https://ci.domain.com/api/secrets?page=1 gets 403

That's a different issue with permissions since we show all secrets in ui (also globals) but if you are not an admin you can't access the global secrets. See #3013