2:43 KeithBonnett1 last changeset before block in east Florida
3:03 KeithBonnett1 blocked
3:15 Roadwaykeith’s first changeset happens to be in east Florida using the same tool in the same editor making the same edits.
Same hours
Cross continent
May I respectively suggest that you calm the (insert word of choice) down and follow the advice that you got from the DWG person** who’s handling the ticket?
I would first suggest that you leave a changeset comment where you believe that the tag added was in error. Providing DWG with example of edits that are wrong would also be helpful.
For completeness, comments on the accounts are here: KeithBonnett1 and Roadwaykeith.
It’s clear that there is a bit of a lack of communication going on here, but what would really help would be to say “User X has added tag Y to way Z, which I know to be incorrect because…”. There are unfortunately no specifics on any of the changeset comments. Also, it’s Christmas - the DWG ticket was created a little under 5 days ago, and people will have been busy with life for the last few days.
** not me
7 Likes
Apologies, I don’t understand tone and didn’t see the point of leaving a detailed comment when Baloo had already asked about all ways being lit=yes.
Mostly I am caught up on whether it’s the same person and what I’m missing.
I’d suggest that that’s less of an issue than the quality of the edits being made (by either account). One of the authors of StreetComplete has commented on the most recent edit; if they ignore that there are definitely grounds for further action.
Links to current blocks: KeithBonnett1 and Roadwaykeith.
1 Like
If this is a widespread thing from this user we really should be rolling back their edits. A lot of stuff got marked lit where the only way it could be is if the earth stopped whilst Oklahoma was facing sunward…
1 Like
It’d be nice to actually get an acknowledgement from the mapper before doing that, but yes - a “big revert” of both accounts’ lit changes is probably on the cards at some point.
For info: latest block
Edit: and here
Edit: Next one here.
1 Like
Roads that user RoadwayKeith marked construction complete: 273 ways
Roads that KeithBonnett1 marked construction complete: 80 ways
I think all tag changes should be reverted where possible.
A lot of the changesets overlap open and closing times and a lot of ways were changed multiple times ie first marking construction complete then lit etc. so I’m not sure what the process would be to get everything to original state.
Roads that Roadwaykeith changed from lit=no to lit=yes 957 ways
Roads that KeithBonnett1 changed from lit=no to lit=yes 382 ways
@SomeoneElse Changeset: 160737357 | OpenStreetMap He started uploading again 2 minutes after block expired.
8 posts were split to a new topic: Unread message notifications not appearing in StreetComplete
Yes, I tried it already, and yes, the SC account I’m using is different. I’ve had no notification there of the unread message. I’ve had one other message to that account, and that did appear, but only several months after the message was sent.
All of these are for the app to decide, but clearly “letting the user know that something is amiss” is something that needs to happen. I’d suggest that displaying the block message also makes sense.
Yes, see above - we’re trying to find a way to actually talk to the user first!
1 Like
Thanks for testing! I was planning on doing exactly this as the first step!
I am mystified by private messages not listed, it is very much “it works on my machine” case but I will look into it 
Maybe some regression happened?
If you want to detect whether the account is blocked, you’d think that /api/0.6/user/details could help because it has active blocks count. But it won’t because you can’t access it while blocked. However if you know your user id, you can open /api/0.6/user/(id) without sending your auth token, that endpoint will show your active block count.
4 Likes
@SomeoneElse I can confirm that missing PM popup is real, I just reproduced it. I will try to investigate further what is going on.
@Anton_Khorev thanks! That looks very useful to avoid ugly hacks of parsing freeform error text
1 Like
There is API for reading blocks, Add show user block api endpoint by AntonKhorev · Pull Request #4240 · openstreetmap/openstreetmap-website · GitHub. The problem is, you need to know your block id but it’s not in the user details/id response. I was thinking about adding it there after I add another thing. That after never happened because you know how osm-website development goes. My next pull request from October 2023 is still not merged.
1 Like
How are block reasons shown to the blocked user on the OSM website? Are blocked users able to log in? Are they able to create OAuth tokens? (which would then return a 403 on trying to use it?) What is the error code when trying to login(?), make changes(?) with a blocked user account? (it’s not documented)
Ideally, the block reason should be shown to the user modally when trying to login (or trying to use a login cookie) before redirecting him to the OAuth authentication. This way, it is guaranteed that the user will see the message when logging in (or trying to) via oauth, regardless of from what app the oauth flow was initiated.
(Except with the shady shady shit OrganicMaps and JOSM do, or used to do(?) with their OAuth flow, where the user would enter the password directly into the app and the app would subsequently fake being a browser towards OSM.)
When this block was active, I logged in as that user in a private browser window and it was displayed. Once I had read it, I could then carry on as normal on osm.org.
If you’d like to do more in-depth testing, the dev api is probably the way to go. My user there is a moderator; it got that status after I asked the admins to make it one. That way, you could test the effects of different sorts of blocks.