Toolforge search results does not show all maintainers.
Ex: Interaction timeline
https://tools.wmflabs.org/admin/tools#!/search/interaction-timeline 2 Maintainers
https://tools.wmflabs.org/admin/tool/interaction-timeline 3 Maintainers
Toolforge search results does not show all maintainers.
Ex: Interaction timeline
https://tools.wmflabs.org/admin/tools#!/search/interaction-timeline 2 Maintainers
https://tools.wmflabs.org/admin/tool/interaction-timeline 3 Maintainers
My first guess was something different about caching between the two views of the data, but looking in the change history I can see that @dmaza was added as a maintainer of the tool on 2017-11-09 so that doesn't make any sense as the root cause.
Are there any docs on how to get a dev environment running locally? I can't find them
The admin tool doesn't have a good local development story. It's tangled up with several data sources that only exist inside Toolforge/Cloud VPS. I've worked on it locally before by ssh tunneling, but its not pretty.
We do have https://tools.wmflabs.org/admin-beta/ as a place to stage and test proposed changes. There is also no special access granted to that tool's processes, so all the things it does should be testable from a tools bastion or interactive session on Kubernetes.
I think the issue is that dmaza is not part of the users table.
On tools.html, it checks that the maintainer is part of users before displaying it while on tool.html displays maintainers without checking. I think that's why we see it on the details page tool.html and not on the list.
I've noticed that my user (ID: 20036) is also missing from the users table in the toollabs_p database. The last user ID added there was 17271.
It seems that the updatetools script is not running on tools-services-* due to a missing service configuration.
Besides that, the script fails to run manually:
tools.admin@tools-services-01:~$ /usr/local/bin/updatetools Traceback (most recent call last): File "/usr/local/bin/updatetools", line 72, in <module> update_users_table(db) File "/usr/local/bin/updatetools", line 58, in update_users_table account = pwd.getpwnam(project_member) KeyError: 'getpwnam(): name not found: legofan4000'
I'll take a look at this later this week.
KeyError: 'getpwnam(): name not found: legofan4000'
legofan4000 was renamed to macfan4000 in T165624 with some manual LDAP LDIF patches. That may have made something horrible for the updatetools script to deal with.
Mentioned in SAL (#wikimedia-operations) [2018-10-16T12:52:39Z] <gtirloni> T186571 removed legofan4000 user from project-tools group (leftover from T165624 legofan4000->macfan4000 rename)
@bd808 thanks for the pointer! User legofan4000 was in LDAP group project-tools and the script was barfing when trying to find the real user.
I've confirmed @dmaza now shows as a maintainer and the users table was updated (went from ~1400 to ~1700 users). The script is running on tools-services-02 as a service.
Mentioned in SAL (#wikimedia-cloud) [2018-10-16T15:13:54Z] <bd808> (repost for gtirloni) T186571 removed legofan4000 user from project-tools group (leftover from T165624 legofan4000->macfan4000 rename)
Mentioned in SAL (#wikimedia-cloud) [2018-11-26T17:34:37Z] <gtirloni> T186571 removed legofan4000 user from project-tools group (again)
legofan4000 showed back in project-tools group and was making updatetools break again. I've removed it a second time.