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

Allow reporting of abusive users to moderators or admins #841

Closed
gileri opened this Issue Nov 20, 2014 · 26 comments

Comments

Projects
None yet
@gileri

gileri commented Nov 20, 2014

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.

@tomhughes

This comment has been minimized.

Member

tomhughes commented Nov 20, 2014

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

This comment has been minimized.

Member

tomhughes commented Nov 20, 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.

@ppawel

This comment has been minimized.

Contributor

ppawel commented Nov 20, 2014

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.

@tomhughes

This comment has been minimized.

Member

tomhughes commented Nov 20, 2014

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

id
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.

@ppawel

This comment has been minimized.

Contributor

ppawel commented Nov 20, 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:

id
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.

@tomhughes

This comment has been minimized.

Member

tomhughes commented Nov 20, 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.

@ppawel

This comment has been minimized.

Contributor

ppawel commented Nov 20, 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

This comment has been minimized.

Contributor

ppawel commented Nov 20, 2014

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

@emacsen

This comment has been minimized.

Contributor

emacsen commented Nov 20, 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?

@Zverik

This comment has been minimized.

Contributor

Zverik commented Nov 21, 2014

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

@tomhughes

This comment has been minimized.

Member

tomhughes commented Nov 21, 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.

@systemed

This comment has been minimized.

Contributor

systemed commented Nov 21, 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.

@rickmastfan67

This comment has been minimized.

rickmastfan67 commented Mar 14, 2015

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?

@emacsen

This comment has been minimized.

Contributor

emacsen commented Mar 14, 2015

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

@grischard

This comment has been minimized.

Contributor

grischard commented Jun 4, 2016

@kocio-pl

This comment has been minimized.

kocio-pl commented Aug 13, 2016

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

@tomhughes

This comment has been minimized.

Member

tomhughes commented Aug 13, 2016

It's pending review, completion and integration.

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

@pnorman

This comment has been minimized.

Contributor

pnorman commented Aug 13, 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

@openstreetmap-website

This comment has been minimized.

openstreetmap-website commented Aug 13, 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 notifications@github.com
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
#841 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABWnLZXNfSOlN_cYU6VZWQzs8lCStc0gks5qfhhIgaJpZM4C-rMw
.


rails-dev mailing list
rails-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/rails-dev

@kocio-pl

This comment has been minimized.

kocio-pl commented Aug 13, 2016

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

@tomhughes

This comment has been minimized.

Member

tomhughes commented Aug 13, 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.

@grischard

This comment has been minimized.

Contributor

grischard commented Aug 14, 2016

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?

@tomhughes

This comment has been minimized.

Member

tomhughes commented Aug 14, 2016

@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.

@tuxayo

This comment has been minimized.

Contributor

tuxayo commented Aug 22, 2016

PR opened

To other people interested: see #1268 for the rest of the story! :)

edit: I'm blind, the PR what referenced just above...

@gravitystorm

This comment has been minimized.

Collaborator

gravitystorm commented Jul 5, 2017

Latest work and comments is now on #1576

@bhousel bhousel referenced this issue May 18, 2018

Closed

Moderation queue #8

@grischard

This comment has been minimized.

Contributor

grischard commented Aug 5, 2018

Since #1576 has been merged, this can be closed!

@tomhughes tomhughes closed this Aug 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment