Skip to content
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

Blocked users can still send OSM messages and raise OSM issues #1946

Open
SomeoneElseOSM opened this issue Aug 12, 2018 · 14 comments
Open

Blocked users can still send OSM messages and raise OSM issues #1946

SomeoneElseOSM opened this issue Aug 12, 2018 · 14 comments

Comments

@SomeoneElseOSM
Copy link

Given that sometimes the reason for a block is that a person may have been sending inappropriate messages, I don't think that they should be able to do this until the block expires.

@tomhughes
Copy link
Member

Blocks are blocks from editing - inappropriate messages are really something that should be raised to admin level rather than handled by DWG unless they're actually related to an editing dispute.

@SomeoneElseOSM
Copy link
Author

Clearly there's a sliding scale of "inappropriate", from "I wouldn't say that to a brand new mapper" (even if what they did isn't very good mapping) through to "that needs to be removed/hidden right now".

@tomhughes
Copy link
Member

Right, but I don't think we can give moderators the right to block messages when they're not even able to see what messages somebody is sending.

Even I have to go in and use SQL if I need to review messages because of a complaint...

@SomeoneElseOSM
Copy link
Author

Turning this around, why should users who have been blocked from editing for good reason be able to send new OSM messages, raise OSM issues or comment on diary entries?

There have been examples of all three recently. To be clear, I don't think that moderators need access to PMs - but if someone has been blocked for personal attacks then it probably isn't a good idea to let them contribute in other ways - e.g. by writing diary comments on a diary entry by a person who has been a subject of a previous personal attack by blocked user.

@tomhughes
Copy link
Member

Well why shouldn't they? Just because they vandalised the map doesn't mean they should be completely excluded.

Obviously some such users will then go on to abuse other communication channels but I don't see why that means they should all be subject to a pre-emptive ban.

Aside from anything else it would prevent them being able to engage with the DWG and discuss their conduct if they couldn't message the person that blocked them.

@woodpeck
Copy link
Contributor

Maybe we're talking different concepts here.

tomhughes, say that a misbehaving user is to be stopped from doing anything in OSM for e.g. half a year. I.e. we want them to not only be unable to edit, but also unable to send and receive messages, write or comment blog entries, or place non-anonymous notes or close notes. But we don't want to delete the account outright. I can see cases where this is likely to be necessary in the future.

What term should we be using for this kind of situation? Would it make sense to speak of "disabling" an account rather than "blocking" it in order to avoid confusion?

Ideally, there should be a publicly visible sign like we have for blocks - "this account has been disabled on by for ".

I know the API doesn't currently have a mechanism to do this but if you wanted to achieve these things manually - could you? And what would you do to make it happen - change the email address to something else, remove the password? And if the account were to be re-activated half a year later?

@tomhughes
Copy link
Member

I can suspend an account but that makes it completely vanish from the site - it will appear much the same as a deleted account and nobody will be able login to it.

@mikelmaron
Copy link
Contributor

Even I have to go in and use SQL if I need to review messages because of a complaint...

Shouldn't we handle this within the app, with a class of permissions specific to it. Rather than jumping into SQL? Someone with those permissions would need to have specific training, and legal agreement to do so.

@tomhughes
Copy link
Member

Well yes of course we should, but oddly something I do once or twice a year is not to of the list of things to make easier.

@woodpeck
Copy link
Contributor

I started a thread on the dev list here https://lists.openstreetmap.org/pipermail/dev/2018-September/030383.html ("Various types and means of account blocks")

@jidanni

This comment has been minimized.

@matkoniecz
Copy link
Contributor

Well why shouldn't they? Just because they vandalised the map doesn't mean they should be completely excluded.

The problem is - as I understand - there is no way to block user from reopening, closing, opening notes and commenting on them. See https://wiki.openstreetmap.org/wiki/User:Mateusz_Konieczny/autoclose_notes_bot_-_potential_target_1 for a partial overview of someone who should be blocked

@tomhughes
Copy link
Member

The problem is - as I understand - there is no way to block user from reopening, closing, opening notes and commenting on them. See https://wiki.openstreetmap.org/wiki/User:Mateusz_Konieczny/autoclose_notes_bot_-_potential_target_1 for a partial overview of someone who should be blocked

That's not strictly true as I can block people by IP address and blocking them by username while it would be easy to add it might well just push people to comment anonymously - notes are unusual in that you don't have to be logged in to use them.

@matkoniecz
Copy link
Contributor

Anonymous notes are far less problematic, as annoying user cannot reopen notes once closed. Or even worse, spam their unwanted content in useful issues.

https://www.openstreetmap.org/#map=14/50.1124/19.9543&layers=N within last weeks had hundreds of spam notes from anonymous account and it is at most mildly annoying.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants