I think that was it.

The same could be said about the opposite (if you like it, create a gadget or user script to add it). Note that this link did not exist until a few weeks ago when the original patch was merged.

This just happened again for me.

What I meant is: the offset you choose in the UI could be relative, and the software would translate it to absolute time for you.

3. A log entry is generated each time the user looks at one page of results. The log entry message could be like $3, $1 got edits for <bdi>$2</bdi> (partial results)

In T311363#8030026, @Dreamy_Jazz wrote:

If T311375 is implemented this may make this less important. However, the way that would be implemented that I see would be basically some sort of offset. This offset could either be time based or ID based, but if this was time based then it would implement half of what this ticket is requesting (as it would be from arbitrary time X defined to end of period).

Between T311375 and T311363 I think this becomes nearly unnecessary and definitely not worth the effort. Decline?

I have found two strategies that would work for me. @JJMC89 and @taavi I would appreciate it if you could advise me as to which you think is best.

I cannot but @LordProfo can. I will send them a reminder on wiki as well.

Support. And what @Zabe said. FWIW, the patches on which @Dreamy_Jazz has reviewed show that they have a good grasp of what makes for good quality code, what makes for a good patch, and how to provide constructive feedback.

I have been thinking about this a lot in the last few days. I am sorry, @Ladsgroup but I think your change should be outright revert. I will create the patch.

In T32790#8018484, @Stang wrote:

Boldly close as I thought this problem no longer exist now.

Oh yeah, I get that. But fixing a regression should not be at the expense of cluttering another interface in ways that would not be helpful 99%+ of the time.

In T310947#8013504, @Ladsgroup wrote:

I originally thought about showing it if the user has cu rights but OTOH, you might need to check logs of a former CU, stewards who has done cu but not cu in that wiki anymore and so on. I know the chances are slim but not impossible.

Yes indeed. Seems like it has nothing to do with Desktop Improvements (Vector 2022) after all. See this rendition on enwiki for instance.

Good catch @Chicocvenancio

Of note, I was able to get my Python code working by using the toolforge library, but am still curious as to why the MySQLdb library doesn't work anymore.

Likely. But the point about an error message shown which appears to only exist in unit test code is also worth investigating.

@Verdy_p please open a new task for this. Let me know if you need help.

I would certainly hope so. But searching for the error message only returns one result, and that is the unit test code I mentioned above.

That is by design, and not specific to Firefox.
The maximum range this tool gives you is /16 for IPv4 and /32 for IPv6
If your input spans a wider range, it'll show an error.

Can you provide an example of a "very large range" so I can test it in Firefox?

My understanding of OOUI is limited, but I guess we now can convert it into a class that extends \OOUI\Widget? If so, then how can we create a multi-component widget? I was thinking that the output should be a FieldLayout that contains a MultilineTextInputWidget (in which we enter the IPs) and a disabled TextInputWidget beneath it (in which the CIDR is shown) followed by perhaps another widget (perhaps a LabelWidget) in which we show the size of the CIDR range.

I will investigate this a bit more, but at least on a cursory look, it seems like the venv that is created by k8s will not work properly on bastion. That is not a deal breaker, but it is a bit annoying that I can only use k8s venvs wit k8s and bastion venvs with bastion. Makes configurations harder to make and test.

I am still having issues.

@Majavah I was unaware of it; feel free to decline this and abandon the patch I just created.

That means IDNUC (i did not understand correctly)!

@bd808 I use this through an alias. Assuming there is interest to make this universal, there are two solutions I can think of:

Ummm. I'm not sure I understand you here.

Those two patches should provide a general sense of what I mean.

I think I can help with coding myself; I was able to find the two places (in the api and the cli Python codes) where changes need to be made.

@JJMC89 no that is not true. The first step in the shell script above is to load a venv, so even with tf-bullseye-std it should still use my venv's python (not the OS python).

@bd808 how difficult is this to implement? Because I am increasingly feeling the need for this.

Update: it is rally exec zsh invoked form .bash_profile that doesn't work. If I put zsh in .bash_profile it works (but then I need to use exit twice to log out of my tool account). If I run exec zsh myself after logging into my tool account using bash, that also works.

Closing as resolved then.

In T309156#7957051, @Lucas_Werkmeister_WMDE wrote:

I have not logged into my tool account for a while, possibly for 2-3 months. Maybe something has changed in the mean time?

Yes, this might be your first time on a Buster bastion (see Stretch deprecation). I guess something in the tool’s zsh config is incompatible with a newer version; you can try to get into the tool account in different ways:

$ sudo -u tools.huji bash # different shell
$ sudo -u tools.huji zsh # non-interactive? not sure if that works
$ sudo -u tools.huji -e ~tools.huji/.zshrc # edit file, comment out the `source` line

After the change, I was able to become huji and then run zsh and on the first run, oh my zsh updated itself and zsh command line became available. Logging out of tool account and trying become huji again was successful again, and I could manually start zsh as my tool account with no issues. Manual start of zsh works both by calling zsh and by calling exec zsh.

Unsure how, but this got resolved.

Today I did not experience this and couldn't replicate it anymore. I will monitor and report if I can or cannot replicate it going forward.

In T217481#7893110, @Daimona wrote:

As I just wrote at T307249#7893101... I'm not sure if it's possible to fix this without making the afl_actions field atomic, which would be nice, but also a big change. @Marostegui, @Ladsgroup do you have any recommendations here?

@Ladsgroup would this be something you could work on in your new role?

Wouldn't be a first. In general, CU code base doesn't handle IP association too well when an action is taking place that typically involves a different number of users than usual (and to all the blame is on CU code, it is partly on how we invoke it through hooks):

We did something similar at fawiki. If you go to MediaWiki:Namespaceprotected (where you have to view source, because it uses an {{#if:... command) you will see that we displayed a message if the logged-out user was hitting the namespace protection for namespace 0. Recall that one of the key differences between the ptwiki and fawiki initiatives was that fawiki only restricted the main (article) namespace.

I created the patch that would revert the config change. I have no availability today personally, but I am hoping that @tstarling or @Urbanecm would be able to deploy this without me being online. It is a revert change after all.

@jeena the comment above is worth your attention. I think we should make sure that commit messages are properly formatted before +2ing any change.

The reason is those two changes did not use a properly formatted commit message; specifically the "Bug: T306030" line at the end of the commit message was missing.

I agree with both comments by @Ladsgroup
For the second one, we should modify purgeOldData.php to also run a query that looks for any rows in the new cu_user_agents table where its identifier (cuua_id) doesn't occur in the cu_changes table in its now-normalized cu_agent_id column. Those rows should then be deleted. This further justifies why cu_changes.cu_agent_id should be indexed, which is desirable for T147894 anyway.

This is a good idea, and would likely make T147894 obsolete. It would also make T234980 much easier.

@Ladsgroup in case you haven't seen this on fawiki's Technical Village Pump, seems like videojs may have some issues for some users.

Thanks for the detailed response.

@Urbanecm given the above discussion and the reference made to https://meta.wikimedia.org/wiki/Logo#Temporary_logo_variants is there a reason you decided to go ahead with this request?

Here is the HTML of one of those notifications from the last test. I see a normal looking <a> tag that doesn't use target="_blank" or anything. (Note that I tidied the HTML for readability)

I also successfully replicated it using User:T304384-2 as the target, and by leaving comments using User:T304384-1 and User:Huji to leave messages.

I was able to replicate it both on Firefox for Mac and Firefox for Windows, using my account (User:Huji) on fawiki. In the last test which I just ran, I used User:T304384-1 and User:T304384-2 to leave messages on my main talk page and used Ctrl+Click (Windows) and see this issue happen.

Since the 6-month period will end in about a month, I want to send another ping here to @jwang and @Niharika and ask for the data in those graphs to be updated.

We've had hundreds of kilobytes of discussion on fawiki about "remove from ranking" (or not rank at all) phenomenon and believe me, many users believe that most user don't understand that no rank = worst possible rank.

Yes, DraggableGroupWidget (vertical) would be a great choice.

@jwang and @Niharika are the graphs on https://analytics.wikimedia.org/published/notebooks/AHT/fawiki_dashboard_last.html fully up to date? I see many whose data ends in late October; given that we are halfway through March, I find that a bit too old, no?

I think this is worth including in the upcoming user notice.

Can you provide some clarity/examples about what you mean when you say numbers with Eastern Arabic nuemrals are RTL'ed?

In T183099#7765456, @Daimona wrote:

In T183099#7762104, @Huji wrote:

No confusion here, @Daimona. The point I am making is: if a filter is both making tons of hits AND exempted from throttle, it could be a big deal. Throttling can at least turn it off after a certain number of hits, thereby saving the servers from the stress, and the users from delayed page loads/saves.

The filter wouldn't be turned off, just its dangerous actions be disabled, but the filter would still be checked for each edit.

In T183099#7762729, @SpookyGhost8 wrote:

The point of being able to have a filter be exempted is to ensure its always running and not needing to inform WMF notice boards or admins of independent third party wikis to reactivate a critical filter that exceeded its hit count.

That point will also be satisfied by having a button that easily re-activates the throttled filter. There is a clear trade-off analysis we should do. The benefit of "exempting" filters is that we don't have to press a button once in a while; the cost is what I described above. The cost of making that "reactivate" button and requiring that a human knowingly clicks it as needed is that a filter may remain throttled for a little (or long?) while until a human reactivates it. The benefit is we are creating a workflow in which checking throttled filters (and potentially figuring out a better way to implement them to avoid throttling) is much more likely to happen; after all, a user has to visit the filter to reactivate it.

No confusion here, @Daimona. The point I am making is: if a filter is both making tons of hits AND exempted from throttle, it could be a big deal. Throttling can at least turn it off after a certain number of hits, thereby saving the servers from the stress, and the users from delayed page loads/saves.

The risk we run there is that someone may unknowingly (or worse, knowingly) create a relative expensive filter, disable throttling for it, and significantly impact server resources and make editing slower. It'll take a while for people to figure out the cause of such disruption.

@Xqt where do the tests get executed currently? On test.wikipedia.org or somewhere else? Asking to know where we need to have the sysop account set up.

This seems a reasonable change to the code.