My apologies for the misunderstanding then.

Actually you are right. A cross makes more sense here since we are excluding from the search in this case

I don't think so. The messages are ready to be translated. I just did es :)

In T212392#5720989, @Ammarpad wrote:

In T212392, @dmaza wrote:

... no changes to the block should take you to the "Block succeed" page

If you did not change anything, then there's nothing that "succeed". Taking person to a success page without doing anything seems misleading to me.
The suggestion by Tbolliger is apt here. If there's no changes to the block at all, the block button should remain disabled.
That sends clear message you should either change something and save, or leave it as it's (no chnage, no save) and navigate away.

So just to be clear, what goes inside the parenthesis in the IP column should be UA independent. Right?

We really need to get more things in writing 'cause I recall having this conversation with someone at some point and completely forgot about it. Having had this information while we were deciding to use a pager or a fake wrapper would have significantly speed the decision and make it easy and obvious (at least to me)

Which icon is better — trash, cross, funnel?

AFAIK a funnel is generally understood as "filter".

In T238714#5705848, @AronManning wrote:

Edits from the same IP are likely logged-out edits from the same user, relevant to the SPI, thus imo it makes sense to include those edits.
If IP Editing Privacy Enhancement moves forward, these edits will belong to an auto-generated user handle, anyway.

@Prtksxna @Niharika
Using the first row on the example table, when we say 1.2.3.4 - 17 edits (10 from 3 other users), the way I see it it breaks down as follows:

• Banana made 17 edits
• Other users made 10 edits
• The total of edits from that IP is 27

In T237296#5697186, @dom_walden wrote:

@dmaza Submitting the Special:Investigate form on a wiki without CentralAuth, I see in the logs:

[error] [f7d4d69c1c92ecf5b9e28a69] /core/index.php/Special:Investigate   ErrorException from line 83 of /var/www/html/core/extensions/CheckUser/src/PreliminaryCheckService.php: PHP Notice: Undefined variable: globalUser
#0 /var/www/html/core/extensions/CheckUser/src/PreliminaryCheckService.php(83): MWExceptionHandler::handleError(integer, string, string, integer, array)
#1 /var/www/html/core/extensions/CheckUser/src/PreliminaryCheckService.php(61): MediaWiki\CheckUser\PreliminaryCheckService->getGlobalUser(User)
#2 /var/www/html/core/extensions/CheckUser/src/PreliminaryCheckService.php(44): MediaWiki\CheckUser\PreliminaryCheckService->getAttachedWikis(User)
#3 /var/www/html/core/extensions/CheckUser/includes/specials/pagers/PreliminaryCheckPager.php(59): MediaWiki\CheckUser\PreliminaryCheckService->getPreliminaryData(array)
#4 /var/www/html/core/includes/pager/IndexPager.php(616): PreliminaryCheckPager->doQuery()
#5 /var/www/html/core/extensions/CheckUser/includes/specials/SpecialInvestigate.php(120): IndexPager->getNumRows()
#6 /var/www/html/core/includes/htmlform/HTMLForm.php(694): SpecialInvestigate->onSubmit(array, OOUIHTMLForm)
#7 /var/www/html/core/includes/htmlform/HTMLForm.php(586): HTMLForm->trySubmit()
#8 /var/www/html/core/includes/htmlform/HTMLForm.php(601): HTMLForm->tryAuthorizedSubmit()
#9 /var/www/html/core/extensions/CheckUser/includes/specials/SpecialInvestigate.php(41): HTMLForm->show()
#10 /var/www/html/core/includes/specialpage/SpecialPage.php(575): SpecialInvestigate->execute(NULL)
#11 /var/www/html/core/includes/specialpage/SpecialPageFactory.php(607): SpecialPage->run(NULL)
#12 /var/www/html/core/includes/MediaWiki.php(298): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
#13 /var/www/html/core/includes/MediaWiki.php(967): MediaWiki->performRequest()
#14 /var/www/html/core/includes/MediaWiki.php(530): MediaWiki->main()
#15 /var/www/html/core/index.php(46): MediaWiki->run()
#16 {main}

I don't know if this is something we need to support.

@Niharika What is the acceptance criteria for this task? Should ip users also be supported as part of this or is it supporting only registered accounts enough?

Waiting on T237532: Preferences are saved as GlobalPreferences when autoglobal is enabled for the field to be fixed

In T235047#5648040, @dbarratt wrote:

@dmaza After the server returns a 301/302 and the page gets redirected... why doesn't the next request (that results in a 200) have the cookies?

In T237296#5660626, @dbarratt wrote:

In T237296#5658378, @dmaza wrote:

Although (and I tried this with GraphQL extension and it works well), you can construct a FauxRequest and pass it to an API module directly... that would allow you to "call the API" without actually opening up another process in Apache. Though, MediaWiki doesn't support "sub requests" like that very well, so not sure how acceptable it would be. Then again, this is an extension, so do what you want. :)

Considering that the use of internal API requests is discouraged I assume that we are mentioning CentralAuth API only if we can't run the db queries and instead we would load whatever we need from the client side using ajax. Am I wrong?

@Niharika Is CheckUser2 the name we are gonna go with? Can we go for something that can stick even if the current CheckUser cease to exists?
Here are some ideas for the name of the page (I know words like "Investigation" carry some weight but maybe somehing similar to that(?)

• InspectUser
• ExamineUser
• CheckUserInvestigation

Writing down what I found

In T199174#5606683, @Sakretsu wrote:

Isn't just $currentBlock->setBlocker( $performer ); missing in SpecialBlock.php?

In T233441#5516930, @Tchanders wrote:

@dmaza - do you have any thoughts on changing the config back to false in core?

Looking into this

Pull Request here: https://github.com/wikimedia/InteractionTimeline/pull/117

@Niharika @dbarratt should we split this up into an server/client task? I'm happy to take on the server side of things

@Jdforrester-WMF Since CommonSettings is currently setting these two configs to true there shouldn't be any problems I assume.

I'd advocate for fixing all at once if there's a clean way to do it. @dmaza did you have a way in mind?

I do not.

I think that's a bit gross. I would honestly rather just leave that English-only than do that.

Do you care to expand on this? I don't think "gross" is a valid argument

In T185785#5414327, @dbarratt wrote:

would we rather:

1. Enable server-rendering which will allow us to display the message in the user’s language. This will require splitting the tool into two tools (which is trivial, imho, and can remain in a single repo if we want): https://lists.wikimedia.org/pipermail/cloud/2019-August/000774.html
2. Leave the app as “static” and display the message in all languages?

@Milimetric @nettrom_WMF correct me if I'm wrong but other than annotating that the schema is active[1] there isn't anything else I need to do to start logging events other than deploying the code[2] that would make use of it, right?

Here is the schema for our data capture. Feel free to make changes and I'll fix up the patches
https://meta.wikimedia.org/wiki/Schema:SpecialMuteSubmit

@dom_walden can you confirm that the issue is fixed tho? (Block list and log incorrectly report "cannot edit own talk page" for some blocks) I'll take a look at how the form displays the errors anyway

In T224468#5393469, @dom_walden wrote:

@dmaza Would it be better if the error message appeared underneath the "Editing their own talk page" checkbox?
This would make it immediately obvious what it refers to and would make it consistent with the location of other error messages (see below).

Makes sense, I'll fix it

In T224468#5375145, @dbarratt wrote:

Works for me.

Great

In T224468#5339366, @dbarratt wrote:

I'm saying you can show the error message, but the field may be disabled, so they may not be able to correct the error.

Sure, lets have another task and we can investigate there

Assuming $wgEnableSpecialMute = true. Neither $wgEnableUserEmailBlacklist nor $wgEchoPerUserBlacklist has to be true, which means you can see this link even if there is nothing you can do with it. I don't know why you would configure your wiki like this, though.

@dmaza I don't think we should show the link if the page is going to throw an error anyways. It's effectively an access denied (and perhaps we could use that mechanism?).

It shows an error message saying "Mute features are unavailable. This might be because: you haven't confirmed your email address or the wiki administrator has disabled email features and/or email blacklist for this wiki. "
We could check for $wgEnableUserEmailBlacklist but we can't check for $wgEchoPerUserBlacklist. I don't think there is anything we can do really other than what's already in place.

In T224468#5329582, @dbarratt wrote:

If a user tries to save ipb_allow_usertalk in a way that does not conform with those rules, an error message should be shown and the block should not be saved.

Or maybe just do the thing that is expected, rather than throwing an error (because if the form field is in a disabled state, you wont be able to resolve the error).
In other words, DWIM.

In T220163#5326499, @Niharika wrote:

@dmaza @dbarratt I agree it seems repetitive. We can make the user's name bold in the sentence above to make it a bit more prominent but let's go with ...from this user for now.

In T220163#5322863, @dbarratt wrote:

Instead of saying "Mute emails from this user" and "Mute emails from this user" would it be better to say: "Mute emails from user ABC" and "Mute notifications from user ABC"?
I was just wondering because when I first come to the page, my brain skips the first line entirely and I read the options, which use this and then I have to figure out what this is.

If the issue is that after unchecking "Editing", "Editing their own [...]" remains checked (although disabled), that will/should be fixed on T221117: Special:Block checkboxes should remember checked state. I personally don't see a problem other than what's described on T221117

I'm a bit confused as to what is the issue here

Expected Result:
Either:
Grey 'Editing their own talk page' when editing blocks are disabled

Isn't this what's happening right now?