It sounds like there is agreement that we show the user the most recent IP we know of and let them know that that's what we are doing. I like the idea of using the info icon to do this.

Let's prioritize this task. We can reassess after testwiki deploy if we see evidence that we need to keep them for longer.

I think this task can be brought in to the sprint now.

We haven't heard any complaints from our previous deploys. This should be good to go now.

In T280531#9664502, @Johannnes89 wrote:

@Tchanders @Niharika any updates when the deployment is going to happen for the remaining 6 wikis? :)

In T326929#9618940, @kostajh wrote:

In T326929#9243280, @Daimona wrote:

Personally, I don't think the TB should be bypassed. If any regexp is preventing the creation of temp accounts, that will appear immediately in the TB hit log, and admins can update the TB accordingly.

That sounds reasonable to me. (cc @Tchanders)

@PBradley-WMF I have included a mock for what this look like in a comment above. Can you please confirm if it looks OK?
And for the link to the policy - the link you provided originally was for the Minimum requirements section. Is that intentional?
The current patch links to the entire page. That can be changed if you feel the section is more appropriate.

Current design:

In T345855#9413880, @Tchanders wrote:

@Niharika Could you provide a link to the user research that prompted this change in the task description?

We have decided to go with serial instead of scramble.

This feature is being scheduled for a complete rollout over the next couple of months. The plan for complete rollout is outlined in T280531: Enable partial action blocks on all Wikimedia production wikis and in MediaWiki by default.

After Chinese Wikipedia's deployment, we will not accept any more pilot wikis. Instead, we plan to deploy to all wikis. The plan for complete rollout is outlined in T280531: Enable partial action blocks on all Wikimedia production wikis and in MediaWiki by default.

@taavi It's good to go.

Thanks for waiting on me. I think we can go ahead on this. Sorry for my late reply!

I can confirm that revealing a user's own IP address to themselves should be OK.

@KSiebert I believe these extensions are also owned by CommTech:

• PageAssessments
• WikimediaOCR
• RealtimePreview

I expect querying older IPs that no longer exist in Spur database would be a valid use case. I don't have a good sense of how important is it for end users (do they run into these IPs once a month? do they run into these IPs a few times a day?). I suggest we wait on user feedback before prioritizing this feature enhancement. We can make this an explicit focus when we gather user feedback after Spur is integrated into IP Info.

@stjn If there is any feedback from the community about this feature (positive or negative) I would love to hear it. Thank you for managing this.

@dom_walden can you confirm if this bug still persists?

+1 to what @Tchanders said. @Samwalton9-WMF we should talk about this.

Let's go ahead with bullet list of the various blocks. Consistent with what we did on T344463.

Based on the feedback, I think we should do the following:

• Adding a line break in $2 of blockedtext-composite breaks the list created by the initial colon, so the real reason appears in its own paragraph with no indent. With a template generating a block-level element, the period after the </em> also ends up on its own line.
• Remove the blockedtext-composite-reason "There are multiple blocks against your account and/or IP address" because that doesn't make sense.
• Loop over all original blocks and show the blockedtext message for each one.

Thanks for the comment @L235. @Xaosflux @AntiCompositeNumber @Izno @taavi as a quick solution for this problem, is the currently implemented solution acceptable?

... show one local block message, but not necessarily the preferred one if there are multiple local blocks

Thanks!