When a user who is not logged in attempts to load Suggested Edits, the user may be shown an "IP blocked" message if the anonymous MediaWiki account associated with the user's IP address is currently blocked. This behavior is undesirable because the anon account may be blocked for reasons having nothing to do with the current user, for example if the user is on a VPN or using a public access point. Furthermore, the message is misleading because it is the (anonymous) MediaWiki user account that is blocked, not an IP address or range block applied at the traffic server layer. Given that login is required to use Suggested Edits, the login prompt should be shown unconditionally.
Description
Description
Related Objects
Related Objects
- Mentioned In
- T281001: [SPIKE] Investigate legacy vs. modern event submission inconsistencies for Android user contribution screen
T228179: Event Platform Client — Android
T281182: Android user contribution screen `ip_block` action value is misleading - Mentioned Here
- T281001: [SPIKE] Investigate legacy vs. modern event submission inconsistencies for Android user contribution screen
Event Timeline
Comment Actions
Feedback by email:
I wanted to do some suggested edits, but I was told that my IP is blocked - I was using 4G instead of the usual WiFi as I was on the move. However I was logged in with my username (Korrigan). Should the IP check really apply when I'm logged in?
Comment Actions
Based on early results (T281001#7057837), it appears that the removal of the pre-login block check eliminated the large discrepancy in ip_block event counts between the legacy and modern systems. I had a hunch that this would be the case, but I don't have a good theory about why. Maybe there is a request IP block list applied at some point to MEP event intake but not applied in the legacy system? I'll bring it up in tomorrow's MEP engineering sync.
Comment Actions
It would've been interesting if we'd released the immediate-sending MEP test before that change. Oh well.