StreetComplete knows the userId from when the user was last logged in. So it could check if there was an active block, but as you said, without knowing the block id, there’s nothing much to do 
Tried it, updated Issue: Ensure that blocked user sees his block-message · Issue #6062 · streetcomplete/StreetComplete · GitHub
I said here that I wanted to add active blocks list to user details/id responses. I tried it and I didn’t like the results. It’s not obvious whether the list contains all blocks or just active ones, to address that I’d need to add active attribute on blocks which I currently don’t have, I put the list inside the element with counts which was previously empty and maybe it’s not the best place etc. Besides you’d still need this remember the id + don’t send the header trick to access that endpoint, which is inconvenient. It’s better to do something else.
Now I want to add another endpoint that will list active blocks of the current user and will be exempt from blocking. The path will be probably /user/blocks/active. It would still require read_prefs scope because /user/details requires it. It will have zero or more <user_block> elements that would at least have id attributes. I’m not yet sure what else would be included because we have Messages API and in that API messages don’t have bodies on list endpoints, body can be seen only on an individual message endpoint. So I’ll do the same for blocks, individual block endpoints already exist.
You’ll request /user/blocks/active. If the response contains no <user_block>s, the user is not blocked. If there are <user_block>s, you can read their ids and request for each one /api/0.6/user_blocks/#block_id which contains the <reason> element with the block message, or send the user to osm.org/user_blocks/#block_id.
3 Likes
Bad news: PM notifications was completely broken
Good news: fix message notification not being shown · streetcomplete/StreetComplete@1a97dfc · GitHub fixes it
Bad news: it needs to be released, fixing code in repo is not magically updating all deployed apps
Thanks for testing to @SomeoneElse
(debugging this and block messages took multiple hours, even if this change is tiny. I fixed a related bug concerning HTTP codes while doing this. Block message not being shown loook more and more like osm.org bug and responsibility, expecting every editor app to include complex hacky workarounds seems like a poor idea.)
6 Likes
With this user, I suspect that it’ll still be the quickest way of communicating with them 
I’ll look forward to the discussion elsewhere about that and will be sure to bring 
!
3 Likes
Just quickly checked 8 year old code on how I handle the issue: the API will return an 403 error on operations that require a login, but are not possible because the user is blocked.
Yes, this is not documented.
If it is any consolation: iD doesn't handle blocked user accounts gracefully · Issue #5400 · openstreetmap/iD · GitHub seems to still be open.
1 Like
sadly, AFAIK, it will return 403 also in some other situations
While that is true (and these cases are documented), I somehow don’t suspect that SC has code to unhide notes and similar operations. With other words you only need to consider what the API calls that you are using return, not everything else.
This section existed for at least five years.
That was actually added by yours truly in February 2017 (I thought it was a bit out of character of me not to document something I had found out about the API) and at that point in time looked like API v0.6 - OpenStreetMap Wiki
It probably be needs to be rearranged now to make clear that it isn’t OAuth 2 specific.
link is broken
It seems that if you mark “Needs view” then you cannot really avoid seeing it, so user likely has seen it.
In my testing I was able to login, give new oauth but it was not allowing to edit so I was kicked out and StreetComplete asked me to lonin again
which is subotimal on its own, but a bit different story
If block is marked as “Needs view” then you need to view it in browser before SC is allowed to continue sending edits.
(and if “Needs view” is bypassed then it is surely osm.org bug)
So unless I missed something, this person has seen the block message at some point?
if anyone can figure out how with “Needs view” block being created, message not seen by mapper and them being allowed to continue editing: how this can be done?
“user is blocked, they end in unclear cycle of confusing UX” is still a bug (in at least one software) but affecting only blocked people so of lesser importance
1 Like
Thanks. I’m currently just escalating block durations until they get bored (after checking that they have not done what we’ve asked, of course).
If they create a new account that’ll be difficult to spot externally (new StreetComplete users pop up all the time - which is great!). Separately from what is written to OSM, does StreetComplete get any indication that a changeset such as this one was added by a non-local user?
They finally replied to a comment saying on this changeset that they were using Google Street View. I’ve therefore reverted what hadn’t already been reverted.
5 Likes