I believe (and @Tchanders / @Catrope please correct me if I'm wrong) that we will be able to tell the user that there may be further data, and that they can "drill down" more by changing the form or the timespan.

Do you mean we won't be finding all the results because we truncate the result-set? Would we be able to tell the user that the results were truncated at $number? And, what do you think the truncation limit would be?

The engineers and @Catrope (thanks!) met to discuss this, and essentially boiled it down to three proposals:

You are not always going to get the full number of rows on each page if, for example, the last page less rows than the limit. Similarly, if you click "Last page" and click through "Previous page" until you get to the first page, you may have less than the limit.

Am I right in understanding from your comment that it's possible to do multiple highlights at once? In that case, are there any technical reasons to introduce a limit on number of highlights allowed?

@dmaza It's explained in T244157#5892494

@Niharika @Prtksxna I have a few questions that arose while working on this:

• Are the round buttons with a white background a literal design? For now I've kept the OOUI design for the toggleButtonWidget. It seems sensible to have the buttons and colours look consistent with the other OOUI components on the site, so that it's clear these are buttons, and clear when they are toggled on/off.
• As we've discussed somewhere before, having buttons that appear and disappear means the rows keep changing height (this is also the case on the prototype). Should we have another task to address this and any other design issues that crop up after seeing the working product?
• Having the pin buttons disappear after a row is pinned makes the UI complicated, because if the check user then wants to unpin that highlight, they may have to look through several rows to find which button they pinned. One solution would be to make all the buttons in the column toggle on and off together, but I think it could be confusing UI to toggle one button on and a different button off. Another solution (which I've implemented) is to keep the pin that was clicked visible when you hover away, but not to show any other pins for the same column. That way, it's clear to the user where they need to click to untoggle the pinned highlight. It also gives a clear indication of how many highlights they have pinned, if they pin several at once. (When many highlights are pinned, it becomes difficult to distinguish between what's highlighted because it was pinned vs because of where you are hovering.) Does this sound OK?

@dom_walden Not sure to what extend this needs testing - it doesn't change the pagers, just how they're created. I checked the pagers are both still there and not doing anything odd.

@dbarratt It's worth bearing in mind the schema change process (https://wikitech.wikimedia.org/wiki/Schema_changes), which needs to be followed when adding indexes. Given the additional costs to storage and table insertions (cu_changes is large and frequently updated), adding four quite specific indexes for this query would be expensive. (Incidentally, I'd question whether the query can use all four indexes, and how efficient that would be if so.)

@dbarratt We should discuss that as a team. Does it impact on whether we do this task though?

@dom_walden This can be tested alongside T244517 and T238808.

@dbarratt Good point.

Wiki

Wiki's name in canonical form

On-wiki user page (red or blue link depending on page existence)

@dom_walden This can be tested with T238808 and T238782

@Niharika The default limit is decided by user preferences in Special:Preferences > Recent changes. We could override that default - is the 100 figure important?

@Niharika Good idea. @dmaza and I have tested, I think that should be enough for such a small change

I have a few questions about the acceptance criteria:

Sounds like this may need an upstream fix in OOUI. Let's leave this open for now (could investigate further why adding TabPanelLayout directly didn't help), but use the style fixes in the meantime.

As @dmaza points out, Flow's HistoryPager is another case, slightly more fiddly to fix since the property needs to not be an array when passed to UUID::create(). While we work this out, we can fix it by doing T244941.

@dom_walden It would probably be easiest to test this together with T238827 and T237298.

Oh, good point. Can we do it conditionally in the code? Would that make sense to do in the extension or elsewhere?

This may be a non-starter for now, because the solution involves exposing the IP of autoblocks in the URL, as the offset.

@Niharika Adding this link would only make sense for WMF sites:

Thanks @dom_walden - filed as T243643

@Niharika @Prtksxna I've made a list of where the links should point to, based on the task description from T237039. I was unsure about some of them - would you mind checking the table and filling in the gaps?

@dom_walden It probably makes more sense to test T238827, T237298 and T239680 together.

@dom_walden It probably makes more sense to test T238827, T237298 and T239680 together.

@Mooeypoo - Have tested the UsersMultiselectWidget and the TitlesMultiselectWidget with throttling, and they both behave the same:

@Xaosflux Thanks for linking to the conversation. The task description says the banner is due to be removed from all wikis today - is that still the case @Niharika, @SPoore?