In T247641#6126157, @dom_walden wrote:

@dmaza @Niharika Some of the issues below might already be raised as separate tickets.

I am including the acceptance criteria from T247640, just so it is in one place:

• Display the list of timeline results (contributions by the users/ips under investigation) in a list, ordered by date and divided by groups of days.

We don't appear to divide by date at the moment.

I think we divide entries by date now. Can you double check this, @dom_walden?

In T251459#6155949, @Tchanders wrote:

Related to this, I've made a separate task for adding the filters that already exist in the Compare tab to the Timeline tab: T253327. (The Timeline results are currently never filtered.)

@Niharika Am I right in thinking that we still want those filters?

Whoops sorry I thought this was an AHT task. My bad.

In T246261#6156074, @Tchanders wrote:

@Niharika @Prtksxna The current implementation allows a user to specify an arbitrary start time via the query string (e.g. 3 days). Is this something we want? If so, should we allow them to specify an arbitrary time via the form too?

In T246261#6156074, @Tchanders wrote:

@Niharika @Prtksxna The current implementation allows a user to specify an arbitrary start time via the query string (e.g. 3 days). Is this something we want? If so, should we allow them to specify an arbitrary time via the form too?

We discussed in our meeting today that this task would be nice to do from a best-practices standpoint but may not provide any significant performance improvements.

In T251361#6148891, @Tchanders wrote:

Are we dropping support for non-WMF wikis?

Also, note that wikis without Parsoid would have everything else except this copy-paste feature - and the reason we're making the copy-paste feature is because it is useful for the WMF workflow.

@Tchanders This ticket was also dependent on the Performance investigation you did. Do you have any recommendations about this task?

In T208645#6142210, @Amorymeltzer wrote:

Isn't the issue with that that the partial block API accepts invalid pages? I think it matters but it'd be a different task.

In T252033#6144234, @Tchanders wrote:

@Prtksxna Yes, normally when you create an account you wouldn't already be logged in, so you'd be an anonymous user from that IP address.

Incidentally, if you do try to create an account as a logged-in user, but it's disallowed by AbuseFilter, the row in the Timeline will link to that logged-in user's page and contributions etc.

To summarize, the way the Timeline is currently working:

• If a logged-out user tries to create an account but it's disallowed by AbuseFilter, the Timeline will show links for the IP address contributions, IP address talk, and Special:Block pre-filled with the IP address
• If a logged-in user tries to create an account but it's disallowed by AbuseFilter, the Timeline will show user links for the logged-in user's user page, talk page, contributions page and Special:Block pre-filled with that user

If we do this task and apply the patch, then if an account is created from an IP address, the Timeline will show links for:

• The non-existent user page for the non-existent user, their non-existent talk page, the non-existent user contributions page, Special:Block in an error state

@Prtksxna @Niharika It sounds like we should decline this task?

In T248241#6141318, @Mandruss wrote:

Why is IP masking moving ahead after 95% community opposition?

In T208645#6139831, @dom_walden wrote:

@DannyS712 With $wgBlockAllowsUTEdit set to false, if I try to submit an empty block I get the exception:
ErrorException from line 889 of /vagrant/mediawiki/includes/specials/SpecialBlock.php: PHP Notice: Undefined index: DisableUTEdit

That option removes the Editing their own talk page check box. I guess you need to test whether it is set first.

@dbarratt What happened to this task? Did I miss an update during standup? 🤔

In T252559#6130411, @Huji wrote:

The bigger issue is that ApiQueryCheckUser.php is replicating code that already exists in SpecialCheckuser.php in an encapsulated way.

Specifically, SpecialCheckUser::doUserEditDBRequest(), SpecialCheckUser::doIPUsersDBRequest() and SpecialCheckUser::doUserIPsDBRequest() should be used by ApiQueryCheckUser.php, for which I think they should be changed from protected to public.

@Niharika is there any plans, as part of CU 2.0, to rewrite the API code base?

Thanks for the thorough review, Dom.

Todo: Change this task to make this limit into a config and lower it.

Yeah, good catch, @dom_walden. I agree, we should revisit how we do this. I will open a new task for that.

In T251932#6124701, @dom_walden wrote:

I don't think there is much I can do to test this, as I don't have a user in the CheckUser group on testwiki.

I see on https://test.wikipedia.org/wiki/Special:ListGroupRights that the "CheckUser" group has "investigate" right. No other group has that right (that I can see).

In T244816#6125307, @Tchanders wrote:

@dom_walden @Niharika Thanks for pointing this out! I thought we'd discussed leaving out N somewhere, but I'm struggling to find it right now...

The problem is we don't know what N is, and we'd need to do another query for each IP and each user in the results in order to find it out. We'd basically need to do the check for all IPs/users in order to find out how many there are.

It's similar to the problem where we've hit the limit for getting edits, but we don't know which target hit the limit without doing more queries. I'd recommend approaching this in the same way - if we feel it's likely to be important, do another iteration see how it affects performance, before we add the extra queries.

In T244816#6018036, @dom_walden wrote:

• There is a button underneath every IP address - Show all N users on this IP

Yep, except we don't show the number of users.

Thanks @Aklapper!

Thanks for reporting this, @MarcoAurelio.

In T208645#6123145, @DannyS712 wrote:

In T208645#6123043, @Niharika wrote:

@DannyS712 Are you going to make a separate patch about blocking empty blocks via the API?

The patch also prevents empty blocks via the API - internally ApiBlock just calls SpecialBlock::processForm

In T252349#6123115, @Pppery wrote:

Is T5595 ("New logo for Udmurt Wikipedia") intentionally listed as related?

@DannyS712 Are you going to make a separate patch about blocking empty blocks via the API?

Thanks @DannyS712. Anti-Harassment can help review this.

I added an investigation task in T252349: Investigation for blocking page creation with partial blocks to answer some open questions before we can work on this task.

In T236299#6121990, @QEDK wrote:

This is quite interesting, is there more information about this somewhere?
Disclosure: I'm part of the SPI team on enwiki.

@DED we could use this task to outline the overall work that needs to be done to port the model in-house. Can you list the next steps in the task description?