Merged. Should be in staging in a few minutes.

When did we introduce this? If we introduced it in a previous (and published) release, we might need to deprecate for the upcoming one? ... But if it's in between releases it's probably fine.

This is the quite entangled view of the "Enhanced" recent changes table. The structure is tabular, but this specific cell has several notations in it (like "N" for new page, etc) and in order to align them across the different entries, the line is either with the symbol, or with a space.

PR is here: https://github.com/wikimedia/eventmetrics/pull/262

Just note that browsers started considering these custom messages as security breach. They allow us to display a warning before navigating away, but not to set the text of that warning.

In T218812#5060050, @Krinkle wrote:

Task description:

If a user adds an expiring item to their watchlist, when the expiration date/time is reached, the item is removed from their Watchlist.

This does not require scheduled execution of jobs. We have various features in MediaWiki already that have an expiry of sorts, which are enforced at run-time. One may be concerned with internal storage allocation, but that is entirely unrelated to any user story or product requirement, and we have existing mechanisms in place to address those. Unless and until there is a problem with that, I do not think we should invest in another way to solve the same problem.

Note also that execution of jobs is by no means guarantee to happen at a certain time. We could maybe ensure it won't execute before a certain time, but not that it won't be a day or a week later. This is precisely why you'll still need run-time enforcement. Which we do already for user rights, page protection, blocks and other features.

I also think that making sure MediaWiki is installable and usable in shared hosting is a worthy goal, and there are definitely some instances where we should be more mindful of it.

In T218812#5042813, @Joe wrote:

@aezell is there something I'm missing? Wouldn't a scheduled periodic job do what you need as well? Or you need precision down to the minute?
in that case, I'm not really sure it can be done with our queue either.

What are the benefits that you see with this approach?

I had a temporary issue with the dev asset build but it seemed to have been fixed. The original idea here is to make it possible to debug in staging and production. If we can do that easily with source maps, we can put those in both staging and production.

So, I'm a bit meh about this; first, I don't like using bits and pieces from different libraries, but that's a minor point. The second slightly more important point is taht if we're serious in allowing users to change their interface language, then some RTL languages have a flipped question mark, which OOUI is supposed to know how to deal with, but FontAwesome doesn't.

Isn't there a flag on the user?

Clarification: Excluding bots, in this ticket, means excluding edits that have the bot flag on them.

@jmatazzoni so, we want to not count edits that were done on items that were created during the event. Is that right?

My suggestion is to drop logged actions completely. As far as I know and as far as I've seen, logged actions are indexed by the performer, not by the user that the action was made to which means that even the action of collecting this data will be risky performance wise, and will increase the level of complexity to consider async delivery and then storage/delivery of files, etc.

In T208636#4991267, @aezell wrote:

This may be obvious. We should have a check deep in the class/function that is grabbing this data to ensure that the user data we are gathering is for the same user that is requesting it. This check should likely happen at multiple layers in the code so we can be as defensive as possible in preventing leakage.

We should think more about how to deal with the possibility that gathering this data will take more time than we want to block the user's browser for. Additionally, if we are collecting all this data into memory before writing it back to the browser as a CSV download or whatever, there could be some performance concerns there.

Just a note, the ViewModel could use the mixin OO.ui.mixin.GroupWidget; the individual input widgets could then be infused and then immediately added through addItems and then we can do this.aggregate( 'change', this.whateverListensToAnyInputChange.bind( this ) to listen to any change event.

I guess that's true, but the benefit of doing my approach is that we're setting up an API for it, which exposes the ability to do what you're suggesting.

Quick clarification (just to save implementation/confusion time in finding the code in the different parent widgets) :

This should be fixed by overriding doInputBackspace from TagMultiselectWidget in MenuTagMultiselectWidget

In T205734#4634253, @MusikAnimal wrote:

In T205734#4631091, @Niharika wrote:

Impose sane limits on the number of pages to process. This is the trickiest part.

I think for the sake of simplicity, for now, we can consider this number to be 50k?

The problem isn't deciding on a number, but actually imposing the limit. Currently we do category tracking as a subquery, and MariaDB apparently does not support LIMIT/OFFSET within subqueries. We'll need to construct a different query that somehow gives us the data we want without putting all the category members in memory. I'm not even certain adding a LIMIT would help, but I've not done any experimentation.

In T210682#4949493, @jmatazzoni wrote:

(If that is the issue, I'm sure we can find a way to handle such errors....E.g., by listing the page IDs that no longer connect to a title at the bottom of report or even just omitting them....)

In T212892#4944350, @TBolliger wrote:

I don't know enough about the 'map' parameter to consider any behaviors that are needed or any edge cases to say how difficult it is to implement.