Openstreetmap-website: Allow reporting of abusive users to moderators or admins

Created on 20 Nov 2014 · 26Comments · Source: openstreetmap/openstreetmap-website

Right now there is no "direct" way to report user who behave incorrectly, apart from the Spam wiki page, which isn't easy to manage.

I tried to start implementing this, but having no prior RoR experience slow me down much, so I figured I should describe here what could be implemented :

A simple "Report" link added next to "Add a friend" on the user profile, leading to page where a logged-in user could select a reason from a drop-down list, and maybe add a comment, to report an abusive user.

The Report model would contain these fields :

emitter (User who click "report")
reported (User reported)
date
reason (enum of reasons)
comment (text)

Possible reasons :

diary spam
changeset spam
diary comments spam
changeset comment spam
GPX traces spam
abusive private messages
offensive avatar
It can be possible to group spam into one reason to simplify.

The deletion of an user (either emitter or reported) must cascade and delete Reports.

A controller/view must also be added in order to allow admins/moderators to view and act on pending reports, grouping them by reported users.

Source

gileri

👍4

Most helpful comment

@grischard Of course, but it will likely be a few weeks before I can look at it because it's a big job and I have a long list of other things to deal with before I can get to it.

tomhughes on 14 Aug 2016

👍2

All 26 comments

I've already described how it should be done in a post on the mailing list: https://lists.openstreetmap.org/pipermail/talk/2014-September/070792.html

I'm less concerned about gathering lots of detail (it's usually fairly obvious what the problem is) than in the fairly tricky technical details of managing the report queue given that it will probably involve some fairly tricky bits of rails like polymorphic models.

tomhughes on 20 Nov 2014

Oh, and I plan on putting the report button on each object (user, diary entry, diary comment, etc) that can be reported, not just on the user, so that we can know what the report relates to as well as making it easier for the reporter so they don't have to click through to the user page.

tomhughes on 20 Nov 2014

👍1

Not sure I understand about polymorphism - wouldn't it make more sense in this case to go with a separate model for reports? If you want to reference from the report the thing it reports and rely on that reference then there's the standard problem of "what if the referenced data goes away?", e.g. someone removes the diary entry or renames it for example.

If you had a separate model then you can copy the data to the report object during the reporting process. Yes it means redundancy but stuff like audit trail or reporting always kind of calls for reduncancy, otherwise it seems pointless or easy to trick.

Or perhaps I am too tired and you meant polymorphism in some other part of this.

ppawel on 20 Nov 2014

Well the table will need to reference the reported objects. I envisage a user_reports tables with columns along the lines of:

user_id
object_type
object_id
reporter_id

Where user_id is the ID of the reported user, object _type and object_id form a polymorphic reference to the reported object (eg DiaryEntry and 23 or DiaryComment and 456) and reporter_id is the ID of the user making a report.

There would need to be an index on user_id so we could find all reports for a user, and a unique index on reporter_id+object_type+object_id to make sure users can't report the same object twice.

tomhughes on 20 Nov 2014

OK makes sense. Do you plan to address the issue with changes to the referenced object?

Not sure if diary entries and users are versioned like geometry is. IIRC, they are not (?) - so you can't link to the actually reported content, you always link to the current version (which can change between the time the report happens and the admin considers the report).

Anyway, what I was talking about is something like this:

user_id
object_type
object_id
object_data
reporter_id

Then you use object_id only for reference and when acting on a report, the admin will judge it based on object_data which is a snapshot of the object at the time of the report. Otherwise the reporter could look silly if they report something and by the time the admin looks at the report, the object is changed to "normal".

Then the question becomes what do you need in object_data to help the admin identify the problem. For users and diary entries I guess you can store the snapshot in the form of serialized data - so for example if the user had some offensive description on their page, the admin will see it in the data. It's harder for geometry but then I guess you don't use object_data at all - simply add object_version to the report table and link the report to the actual geometry version.

ppawel on 20 Nov 2014

Well neither diary entries nor diary comments are editable at the moment are they? It's been requested by I don't think either supports it currently?

Anyway, if the offending content is removed before the moderator looks at it then there's no longer a problem really. I wouldn't expect a moderator to ban somebody in that case unless it happened repeatedly. It's vanishingly unlikely anyway - the serious cases are "drive by" and they aren't going to hang around to edit anything.

tomhughes on 20 Nov 2014

Oh how many times I had something unlikely happen with my code in the most unexpected moment :-)

Anyway, it was just a suggestion, it does complicate things considerably, on the other hand it makes the solution a bit more fool- and future-proof but perhaps it's not worth it.

ppawel on 20 Nov 2014

(Although regarding complicating things - polymorphic ORM mapping always is a tricky issue so perhaps the complexity is comparable? Not sure.)

ppawel on 20 Nov 2014

Tom,

While I like your idea generally, and think it's probably the right way to go in the long term, what about something as simple as an email being generated for now?

emacsen on 20 Nov 2014

Why all these IDs, when you can just store an URL?

Zverik on 21 Nov 2014

Because we've heard of referential integrity?

More seriously, because we want to be able to present a nice UI to moderators showing the reported content and letting them take action on it. Now sure we could parse a lot of that out of a URL but it's pretty horrible when we can just do it properly. It also avoids all the URLs being invalidated if a user changes their name.

tomhughes on 21 Nov 2014

Diary entries are editable - IIRC I added that years and years ago. But, as you say, if the offending comment is removed then the question is moot.

systemed on 21 Nov 2014

Will it also be possible to report anonymous 'notes' when the notes are completely inappropriate and need to be 'hidden' when just closing them wouldn't do?

rickmastfan67 on 14 Mar 2015

Hiding notes is a moderator task, but eventually I'd like to see this functionality expanded to moderators as well as administrators.

emacsen on 14 Mar 2015

If someone wants to work on this, some work has already been done:

https://www.openstreetmap.org/user/sbagroy986/diary/35257

https://github.com/sbagroy986/openstreetmap-website

grischard on 4 Jun 2016

@grischard Is it still a proof of concept or there's a chance to have it deployed?

kocio-pl on 13 Aug 2016

It's pending review, completion and integration.

It's not a proof of concept, it's an incomplete GSOC project.

tomhughes on 13 Aug 2016

If anyone wants to take up completing the GSOC project I rebased it earlier this year to end up with https://github.com/pnorman/openstreetmap-website/tree/moderation_rebased

@woodpeck added a commit with https://github.com/woodpeck/openstreetmap-website/tree/moderation_rebased

pnorman on 13 Aug 2016

It wasn't incomplete.

It was pending review by you (Tom) and final changes.

The difficulty I had in getting this done is a big reason why I didn't
volunteer for any more OSM related programming projects.

Serge

On Sat, Aug 13, 2016 at 3:17 PM, Tom Hughes [email protected]
wrote:

It's pending review, completion and integration.

It's not a proof of concept, it's an incomplete GSOC project.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/openstreetmap/openstreetmap-website/issues/841#issuecomment-239637004,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABWnLZXNfSOlN_cYU6VZWQzs8lCStc0gks5qfhhIgaJpZM4C-rMw
.

rails-dev mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/rails-dev

openstreetmap-website on 14 Aug 2016

Just being curious: could you tell what was the main source of this difficulty?

kocio-pl on 14 Aug 2016

@emacsen All I really meant by "incomplete" was the GSOC project was incomplete in as much as the student never opened a PR to request integration of the results.

I believe I did some ad-hoc reviews of the code for you, but really the final goal is to get a PR opened and do a full final review against that PR and get any final fixes made so we can merge it, which worked well the previous year but seemingly didn't in this case.

That's all in the past anyway - what we need to do now is to get this reviewed, get any changes made if there are any issues, and then get it merged and deployed.

tomhughes on 14 Aug 2016

👍2

PR opened. It's easy, in open source projects especially, for new features to get stuck in limbo, and we shouldn't waste too much good will on assigning blame. Our efforts are better invested in getting this deployed now. Onwards and upwards.

@tomhughes will you be reviewing the PR? Will you comment on what the final fixes are that now need to be made?

grischard on 14 Aug 2016

❤2

@grischard Of course, but it will likely be a few weeks before I can look at it because it's a big job and I have a long list of other things to deal with before I can get to it.

tomhughes on 14 Aug 2016

👍2