-
Notifications
You must be signed in to change notification settings - Fork 1k
Add show user block api endpoint #4240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
#1618 seems to be related to this one |
tomhughes
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we be adding JSON output as well?
This PR alone won't be enough for what was originally asked there. The next required thing is a search endpoint with the ability to search by usernames/ids.
Yes, if the xml output format is ok. The biggest decision here was to make separate user/creator/revoker subelements. |
20da4c6 to
9442829
Compare
|
I assume there's nothing being exposed here that isn't already visible through the web interface? I think pretty much everything is visible there already? |
|
As a normal user, I don't see any of the "uid" values in the web interface, neither for the user which has been blocked, nor for the creator and potential block revoker. By the way, does this also work for deleted users, like this one: https://www.openstreetmap.org/user_blocks/14719 |
| before_action :set_request_formats | ||
|
|
||
| def show | ||
| raise OSM::APIBadUserInput, "No id was given" unless params[:id] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe make it a bit clearer, which "id" we expect here, like "No user block id was given".
Right, but in general the mapping between username and ids is not hidden - the user details call will get it for example. |
|
The web interface prefers to work with usernames while the api prefers user ids. For example you need a user id for user details. When you know a username and want to get the corresponding id through the api, you typically do a changeset search by the username and get the id from the search results. It's only difficult to do if the user has no contributions, but then, if it's a genuine user and not a pre-blocked vandal account, there has to be a problem with their contributions and changesets (or notes) searchable by the username exist. |
Going through the DWG Wishlist, there was a blocks api.
Currently scripted blocks in osmtools are done by emulating the browser, loading webpages and filling out forms. That requires passing the password around. It would be better to be able to access block functionality with a proper api and an oauth token.
But before doing block creation, there need to be block read api endpoints. Here the xml block show method is added at
/api/0.6/user_blocks/:idwith an output like:All of this is already accessible through the web ui at
/user_blocks/:id.