See also: T382491: "Editing own talk page" always checked when loading existing block via id param (fix there is likely the same for this)

Stalling as requires clarification noted above.

For clarity, am I correct in reading this task's acceptance criteria as:

• Change unblockip (i.e. the special page title, header and form legend) from Unblock user to Unblock target
  • nb. I'll create a new message, unblocktarget for this.
• Change ipaddressorusername (i.e. the helper text/label above the form input for the target) from IP address, username or block ID: to Provide a user name, IP address, or block ID:
  • nb. This seems inconsistent with the use of "target" above.

No longer related to a commtech task, rm project :-)

I just +2'd the patch for T381493, so moving this to QA

nb. covered by T381493: Always expand Active Blocks accordion when target is selected and page is not in add/edit mode I think — the "new block" button is in the accordion, and this will be open by default (therefore the "new block" button will always be displayed when a user has been searched for)

In T382339#10414235, @MusikAnimal wrote:

I think the real issue here is that logging don't support ranges (T146628), so you have to enter the exact address the server placed the block on when querying the block log. Fortunately the Block API returns that address, so maybe it's easier to update the targetUser after submission?

Okay, now it's a little more reproducible! It only seems to work in the manner that you describe above (i.e. entering a non-normalised IP CIDR in the input)

Can you retry? I'm no longer able to replicate this bug..

Can replicate, however noting that trying with 1.2.3.0/24 (which contains the blocked 1.2.3.4/30) did work as expected (i.e. block log entry appeared after block)

^ was just +2'd (thanks Sam!) and should resolve the issue :-)

In T379255#10405644, @dom_walden wrote:

@TheresNoTime Should the link be to MediaWiki:Ipbreason-dropdown, not MediaWiki:Blockreason-dropdown? On beta at least the former link seems to control what is shown in the dropdown menu.

Yup, it was :-) reassigned

I could be looking at the wrong design in the link above, but is there meant to be a pipe between the two links?

Grabbing task for this part of the fix.

will unlick as I think @Samwilson will have this covered (as mentioned above)

Blocked on this discussion now, afaict.

nb. looks like this functionality is applied in this patch for T381342: Special:Block empty state. Hide the block form until user clicks "new block" or "edit", but I'll grab it and follow-up on that iff not

Already being worked on as part of T381342: Special:Block empty state. Hide the block form until user clicks "new block" or "edit" it seems :)

+2'd

+2'd

In T380537#10346360, @LucasWerkmeister wrote:

• a SECRET_KEY – if it’s anything like Flask / ItsDangerous (and it sounds like it is), this is used to sign the session cookie; probably not much harm in keeping it, but I could also see some value in refreshing it (effectively logging everyone out of the tool, so they can log back in and start with a fresh session)
• the database credentials in replica.my.cnf – the policy asks us to delete these (and I believe there is a process for regenerating them), though it’s not really clear to me what the point is… are we supposed to also clear s54856__bullseyedb in ToolsDB?
• an IPCHECK_KEY – I assume this is used with some external service that I know nothing about
• a SPUR_KEY, as you mentioned – ditto
• a SHODAN_KEY – ditto
• an OAuth client credential pair for the bullseye consumer – as the consumer only has the user identity verification grant, I think we can justify keeping this one, even if the policy doesn’t have an exception for it

Can you shed light on some of these? :)

In T380193#10342014, @RoySmith wrote:

I love Bullseye, but I just don't see the point of continuing to maintain it when there's a WMF-supported service that basically does the same thing. If there's something Bullseye does that IPoid doesn't, then merge it into IPoid.

And certainly, having a single service that's hitting the external Spur API will give us better ability to monitor usage, and provide performance enhancement with a cache.

I noted on that PR:

Thinking out loud, given that iPoid-Service exists, perhaps an API call to that can be used in place of Spur directly?

I've made a backport patch — I'm around to do this today if needed, but given it's a Friday can it wait until Monday?

nb. created a revert (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1091470) and then made a patchdemo using that patch — issue is reproducible on a patchdemo running latest core (e.g. https://167789d4d8.catalyst.wmcloud.org/w/), but not once that change is reverted.

In T379983#10324858, @Jdlrobson wrote:

Yep that matches the errors I'm seeing in logstash. @TheresNoTime are you able to update the description with replication steps? Can you replicate the issue locally (and if so can you fix it by reverting https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1088731 ?)

Maybe related, I've just noticed that I'm getting a load of Uncaught InternalError: too much recursion console errors when searching (Vector 2010) and using arrow keys to navigate the search results is not working as expected (gif below, I am just pressing the down arrow):

Acceptance Criteria changed per today's stand-up/planning — this is no longer a cosmetic change and requires functionality:

• Clicking "Edit" should take you to Special:Block/{username}
• Clicking "Remove" should take you to Special:Unblock/{username}