Meta:Requests for bot status/MissingCastlePicturesBot
- MissingCastlePicturesBot (talk • contribs • deleted user contributions • logs • block log • abuse log • CentralAuth • stalktoy) Bureaucrats: user rights management.
- Bot owner : Chilfing
- Aim of the bot : This bot's purpose is to update Wikimedia CH/Burgen-Dossier/FehlendeFotosinWikidatabzwCommons every 2 hours, so that the list with castles without pictures stays up to date.
- Script used : add_text_to_wiki.py based on data collected by Burgen_Schloesser.py
- More Information : repository
Thanks --Chilfing (talk) 10:13, 15 October 2019 (UTC)
- Support approval. Given the low edit rate of the bot, a bot flag might not be needed at this stage unless the operator wants it anyway in which case I'd not really object. —MarcoAurelio (talk) 10:19, 15 October 2019 (UTC)
- Support --Krd 11:31, 15 October 2019 (UTC)
- Support bot seems fine, suggest not using a bot flag for this task - it is low enough volume to not impact recent changes feeds. — xaosflux Talk 17:06, 15 October 2019 (UTC)
- Done. Bot is approved to do the mentioned task. Bot flag doesn't seem to be needed for now. Matiia (talk) 01:47, 18 October 2019 (UTC)
ipblock-exempt flag request
edit(was: Bot flag reconsideration)
For the sake of simplicity, we let the scripts that constitute this bot run on the GitLab CI/CD of the GitLab project where the code is hosted. This means that the machine the bot runs on will be an arbitrary GitLab CI/CD runner out of the ones provided by GitLab.com to their users for free. The IP addresses of some of these runners are hard-blocked giving m:NOP as the reason, which causes legitimate edits attempted by this bot to fail whenever it happens to run on a runner on the block list, even though it authenticates with its dedicated user account User:MissingCastlePicturesBot.
While the public GitLab.com CI/CD runners aren't exactly open proxies, blocking their IPs is probably warranted, as they (by design) allow arbitrary code execution to any GitLab.com user and thus could be used for similar abuse as an open proxy. Whether it should be a hard block that also prevents authenticated editing from these IPs, I don't know. Though as, if I understand correctly, accounts with the bot flag are exempt from IP based blocks, I think granting the account that flag would be the most sensible way to avoid its edits being blocked without having to move the execution to a different platform.
Kindly let us know how to proceed. Should we use Template:Unblock on User:MissingCastlePicturesBot or is here the right place to ask? -- das-g (talk) 10:31, 25 June 2020 (UTC)
- I'm not sure if the bot flag would be the solution, given that Special:ListGroupRights#bot doesn't list ipblock-exempt. But the separate ipblock-exemption group is probably the solution then. --MF-W 11:37, 25 June 2020 (UTC)
- Ah, I wasn't aware that what flags include what other flags is different from wiki to wiki. I probably came across documentation that was specific to English Wikipedia, where
bot
impliesipblock-exempt
. --das-g (talk) 13:23, 25 June 2020 (UTC)- Martin Urbanec gave you ipblock-exempt now. --MF-W 11:29, 26 June 2020 (UTC)
- Thank you. That seems to have solved the issue. -- das-g (talk) 12:44, 26 June 2020 (UTC)
- Martin Urbanec gave you ipblock-exempt now. --MF-W 11:29, 26 June 2020 (UTC)
- Ah, I wasn't aware that what flags include what other flags is different from wiki to wiki. I probably came across documentation that was specific to English Wikipedia, where
- ipblock-exempt flag was granted (also to User:OSMCastleBot) and that now lets the bot operate correctly irrespective of what runner it ends up running on. I'll thus remove this transclusion from Meta:Requests_for_adminship#Requests_for_bot_flags again. -- das-g (talk) 12:44, 26 June 2020 (UTC)