Tue, Oct 8
T184075 was an attempt in this regard. I have the result of that analysis somewhere.
Just a quick reminder to all that we are less than a week away from the first step mentioned above.
Sat, Oct 5
Fri, Oct 4
Mon, Sep 30
Great. I will investigate more to see why BotPasswords doesn't retain the session info, but if it takes too long, we can merge the patch as is (it won't cause an extra login if session info is retained).
Fri, Sep 27
@revi in addition to my request above, can you also checkout the 3rd version of that patch set and confirm that it works?
I modified my config to use BotPaswords just like you, and then I forced my bot to log out (python3 pwb.py login -logout) and log back in. Then I ran the script; both with and without the -user argument, it would give me the "Can't delete" message, meaning that it forgot who it was logged in as.
Thu, Sep 26
Tue, Sep 24
@Daimona can I ask you to work on this?
@revi can you share with us the relevant portions of your user-config.py (after redacting passwords and such) please? I want to know how you are using usernames to define your main bot account, any additional bot accounts, and the passwords for them, so I can replicate your setup as closely as possible.
I have one more thought. Let me try that (may take me a day or two).
I was wrong about the cause, but now I know the cause. Here is the line of code that causes it to happen: https://github.com/wikimedia/pywikibot/blob/master/pywikibot/page.py#L1922
Got it. I can confirm that I can replicate it. My suspicion is that the -user parameter is causing it somehow. Investigating.
Sep 23 2019
@revi: Can you please provide an excerpt of the code you are using (or if it is the vanilla delete.py, how you are calling it)?
Sep 20 2019
Sep 18 2019
Fair enough. Thanks for the detailed explanation!
My current use case is to allow eliminators to have access to those features of Twinkle that have to do with deleting pages (currently, Twinkle restricts that script by checking the user's right).
The mw.user.getRights() approach works (and thanks for educating me on it). However, it is an async solution. Having something like mw.config.get('wgUserRights') that is available as soon as the page is loaded and can be used in a synchronous way would be awesome. Indeed, I don't see much value in the getRight being asynch because typically we don't expect a user's rights (or group memberships, for that matter) to change so often that we would want to query the API each time.
Sep 17 2019
Sep 15 2019
My intent was not to criticize you, personally, @Krinkle. What I am trying to figure out is why in that RFC we never mentioned that there exists a group of sysadmins, yourself included, that already have the rights and permissions to modify filters for technical reasons only. I think the responses to that RFC would have differed if the participants knew that a group like this already exists. Right now, their point of reference is the Global Sysop group (which is significantly restricted by the opt-out process).
@Daimona @Krinkle on one hand, we have https://meta.wikimedia.org/wiki/Requests_for_comment/Creating_abusefilter-manager_global_group in which there is ongoing debate about whether a central user should be allowed to modify filters on different wikis; and as you know, I got Global Sysop rights explicitly to do that but it is limited to wikis that have not opted out.
Sep 13 2019
Sep 10 2019
Sep 8 2019
Declindes in favor of T200703 and it associated patch at https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/533728/ which will eliminate subcats form the results of RandomInCategory altogether.
I am going to venture a guess that this is a Chrome-specific CSS problem similar to T232085, i.e. the "hamburger" icon comes from a ::after or ::before CSS rule, and Chrome messes it up in RTL settings. Can someone check with Safari too? Of note, and similar to T232085, Safari seems not to be affected. So this is likely not a WebKit issue, but specifically a Chrome issue.
Nonspecific. It happened to me at random and then it resolved itself. I am guessing there was a temporary issue with connecting to the database.
Sep 7 2019
I officially announced the deprecation in https://lists.wikimedia.org/pipermail/pywikibot/2019-September/009955.html
Sep 6 2019
Understood. I am going to mark this as resolved for now (the purpose of the task was to figure out ways that could potentially make the filters faster, and we have achieved that).
Sep 5 2019
Sep 4 2019
I was wrong. it appears we don't do a good job in mapping Arabic and Persian digits to those used in Latin-based languages like English, etc.
Wouldn't ccnorm() get the job done? To the extent I recall, ccnorm('1') == ccnorm('۱') and so forth.
@Daimona here is where I have a problem with this: we have unit tests that create filters. How come none of them failed with I6436c7d2df8c1f0fc971f4a4079dac9118aa8209 ?
Sep 3 2019
This is the part of code that prevented me from moving that flow board. It checks to see if I have the flow-create-board right (which I do not) and I cannot find any way this can be circumvented, as is, outside of giving flow-create-board right to admins (which, I'm not sure is desired or not). The reason I think so is because this permission is checked every time Hooks::onMovePageCheckPermissions() is called, which is literally on every page move.
Sep 2 2019
Aug 28 2019
Oh, I see. I was using 1.26.0 and now I upgraded to 1.28.0 and things work smoothly.
This was fixed in upstream about a year ago, yet on our instance of gerrit for WMF this issue still prevails.
Aug 27 2019
Correct. What I was trying to say was that we should not spend clarifying how to do that (updating documentation, etc) right away.
Aug 26 2019
Once https://gerrit.wikimedia.org/r/#/c/pywikibot/core/+/532473/ is merged, we are all clear (given the exclusions we have specified in tox.ini of course) and we can close this task. CI already takes care of the rest.
@Xqt from what I can see, the only issue pycodestyle finds with our current scripts is lack of compliance with E731 (do not assign a lambda expression, use a def) which happens with only the following:
I am assuming r531589 fixed this. Reopen if otherwise.
I am assuming r531589 fixed this. Reopen if otherwise.