Report a Topic

[tiblu]

There is a way to report an argument (comment) but not a whole Topic.

TODO

• API - create report POST /api/topics/:topicId/reports.
• API - create report POST /api/topics/:topicId/reports to return moderation URL instantly when reported by a moderator, this will enable instant moderation without sending an e-mail.
• Emails - move to Crowdin (E-mails - localisation with Crowdin #41)
• API - unify restricted token generation and validation (API: Unify restricted use token generation and validation #70)
• API - read a report GET /api/topics/:topicId/reports/:reportId
• API - moderate a report POST /api/topics/:topicId/reports/:reportId/moderate.
• API - review
• FE: Report a topic menu item
• FE: Report a topic form
• FE: Report moderation menu item - **DONE: ** Not separate menu item but part of the red notification on the top.
• FE: Report moderation form
• FE: Moderated topic visuals - warning overlay etc. - https://projects.invisionapp.com/d/main#/console/9829159/333531893/preview https://projects.invisionapp.com/d/main#/console/9829159/333531894/preview
• FE: No search engine indexing for reported content! - in the initial scope, only GET /topcs/;topicId, other views need to be addressed separately - Report a Topic #5 (comment)
• FE disable/hide upvote/downvote when not logged in
• FE: Missing report topic icon on the top right of the topic!
• FE: Disable action buttons when request is in progress!
• Emails: As described in https://app.citizenos.com/en/topics/ac8b66a4-ca56-4d02-8406-5e19da73d7ce
• E-mails: linkedData usage is funky.
• E-mails: Get rid of social: config.email.social option?
• E-mails: Application links in the emails are same for all languages, we may want to support links per language? DONE: Overthinking this? FE can will do the language resolution.
• E-mails: Moderation guidelines links! - DONE: Can be changed with config.email.linkViewModerationGuidelines. Defaults to https://app.citizenos.com/en/topics/ac8b66a4-ca56-4d02-8406-5e19da73d7ce
• E-mails: Date formatting! DONE: - LLL Z
• E-mails - TESTING: REVIEW SEND TO PARLIAMENT E-MAILS!
• CHANGELOG.md
• DB migrations!

[tiblu]

Assets (sorry, not public yet): https://projects.invisionapp.com/d/main#/console/9829159/241763981/inspect

[tiblu]

@loorm What do you think we should do when a Topic gets moderated?

I think we should follow our rule of hiding not deleting.
We should also consider a situation when the Topic gets fixed, then we could make it visible again.

[tiblu]

I am to create some new e-mail templates so I created a side track - #41 and will fix this before I complete this task.

[tiblu]

Marked as "blocked", we need to discuss what the UX will be.

The questions are:

• IF a Topic gets moderated, what will be shown in the FE?

All the work done so far is in the "report_topic" branch - https://github.com/citizenos/citizenos-api/tree/report_topic

[loorm]

My 10 cents:

• both public and private topics can be reported, regardless of their status (even closed topics, because they are still visible)
• reporting should be similar to argument reporting (same reasons, same dialog asking for explanation)
• any logged in user should be able to report any public topic (need to check legals, if non-logged in users also need to be able to report)
• if a public topic is reported, it is automatically switched to private, pending fixing or moderator decision, if topic is in voting, voting should be halted - THIS IS AN IDEA TO BE DISCUSSED
• moderation cycle should be started similar to argument reporting incl. topic owner notification etc.
• there should be a clear notification / overlay to indicate, that the topic contains potentially offensive material, that has been reported, the decision is pending and user should read on at their own risk
• if a topic is found to be offensive and author does not fix, we don't show it on front page, but possibly will show it to subscribed users, only with an overlay similar to "deleted" arguments.

[tiblu]

The proposed mechanics with @loorm @kevincrepin @tiblu

• You can report both public & private Topics
• Report notification/email:
  • Private topics - to creator, admin level members
  • Public topics - to creator, partner/global moderators, admin level members
• What happens to reported Topic?
  • Nothing happens on report itself (before moderation)
  • When moderated:
    • Hide from Home page default view
    • Home page new filter to show "moderated" Topics
    • Overlay the Topic in READ ONLY view, with "Show anyway" action
    • Notification bar in EDIT MODE ("Youre editing reported topic") for all views (voting, followUp, closed)
      • Show count of reports
      • Show link to moderation guidelines
    • EDIT MODE has "Submit for review" to notify Moderators that the violation has been removed.
    • No search engine indexing of moderated topics.
• Report reason "Contains spam or is unrelated to topic" REMOVED for Topics
  • Split into 2 "Contains spam" / "Unrelated to Topic"
• IF a reported Topic gets exported, it will have notice in the final document about being reported with the violation reason.

Open questions:

• ANY user can report? NO, read below (Report a Topic #5 (comment)).
• Can we share reporters contact info with Moderators to ask for clarification? YES, TOS update. (Report a Topic #5 (comment))
• Do we need to report private topics? NO (Report a Topic #5 (comment)).

[kevincrepin]

Couple more questions from my end:

• Do we show who reported the topic publicly?

• When reporting, is the additional text field obligatory? Do we show that input publicly?

Overlay: https://projects.invisionapp.com/d/main#/console/9829159/333531893/preview
Notification: https://projects.invisionapp.com/d/main#/console/9829159/333531894/preview
Edit mode: https://projects.invisionapp.com/d/main#/console/9829159/333531895/preview

@tiblu let's discuss when you're back from vacation.

[tiblu]

My 10 cents on the @kevincrepin questions:

Do we show who reported the topic publicly?

No, I don't think so.

When reporting, is the additional text field obligatory? Do we show that input publicly?
Not obligatory for arguments right now, so it's not obligatory for Topics for consistency.

Yes, the input is shown publicly.
I think we should consider making it compulsory to make a person think if the violation actually is there (take out the emotional aspect) and help moderation. Always good to explain your actions. WDYT @loorm?

Overlay: https://projects.invisionapp.com/d/main#/console/9829159/333531893/preview
@kevincrepin @loorm
Not sure we want to show such detailed info? Maybe just a number of reports is enough or?

@loorm Is there any progress on the open questions from legal side:

Open questions:
ANY user can report?
Can we share reporters contact info with Moderators to ask for clarification?
Do we need to report private topics?

[tiblu]

Created #70 to unify token usage before we start issuing new tokens for Topic Moderation.

[tiblu]

Differences between current argument (Comment) and new Topic moderation solutions

Ideological differences

NOTE: We use Arguments term in the UI, in the DB and technical discussions we use Comments. So, we use Comments here.

Terms:

• report, reporting - A User generated violation report.
• moderation - A Moderator has approved a report, thus restrictions apply to content.

Differences:

• Editing content
  • Comments - Once a Comment has been moderated, User cannot edit the comment.
  • Topic - User can edit Topic moderated or not.
• Reversal/disputes -
  • Comments - Once a Comment has been moderated, there is no reversal - you cannot dispute the moderators decision and make it visible in the UI. It's forever hidden from default views.
  • Topics - Once a Topic has been moderated, User can dispute the moderators decision with "Send for review" feature. Same feature can be used to lift the restrictions from Topic after User has edited the Topic.

After we have implemented the Topic moderation, it makes sense to review both solutions and unify to whichever works best.

Database schema differences

Notes on the DB differences:

• Comments schema clutters entity (Comments) table, when reporting capability is added by adding fields deletedByReportId. To clarify fields deletedReasonText, deletedById, deletedReasonType ARE NOT moderation specific - if User deletes his own comment, these are filled as well.
• Comments schema does not support disputes & reversal.
• Comments schema creates an intermediate CommentReports table which adds un-necessary complexity to the DB. The initial idea of the intermediate table was to have single Reports table and several different entities that can be linked to Reports without loosing the power of FK/PK constraints to guarantee DB integrity - that is, not to have ambiguous UUID in the Reports table that can reference any entity (Topic, Comment, User...).
• Comments schema guarantees consistency by using single Reports table.
• Topics schema supports disputes & reversal via resolvedById and resolvedAt columns. When a dispute/reversal request is made using "Send for review", Moderators get an e-mail, which grant them permission to approve changes and lift restrictions. At that time resolvedById is the Moderator id and resolvedAt is NOW().
• Topics schema guarantees consistency by extending Reports model - same solution as TopicMemberUsers/Groups extend TopicMember.
• Topics schema enables simpler queries.

Other thinking points

• What if we also start using deletedBy, deleteReasonType, deleteReasonText for Topics? This would enable Users to leave traces behind of why a Topic was deleted and we can show these reasons to Users requesting the Topic. The traces (deleteReasonText) could possibly link another Topic which was created instead or smth. The CON part of it is that if we request a reason for every Topic, it may become annoying to Users and clutter the UI.

@ilmartyrk Please have a look if this all makes sense to you, is there anything unclear or something you find weird?

[tiblu]

@loorm

Notes on the Topic report implementation v1:

• In this scope, we have resolved the Topic view (/topics/:topicId), but in the future we MUST tackle other views that expose Topic content. See Report a Topic #5 (comment)
• Currently we create no activities to the activity feed about the reporting. We need to agree what activites we want to create.
• The community guideline links in the emails and the FE take to Citizen OS Topic Moderation Topic. We need to polish it's content. https://app.citizenos.com/en/topics/ac8b66a4-ca56-4d02-8406-5e19da73d7ce
• Currently we hide "Report" actions when Topic has already been reported and is waiting for Moderator action. Maybe we want some other UX, to let Users know that it's pending Moderator review?
• While you can have one report request at the time, we allow multiple "Review" requests, each sends Moderators a new e-mail. We MAY want to reconsider it - make 1 review request be open at the time, but then that means we have to have a means keeping track and closing review requests. Right now review request only sends e-mails, it has no state stored in DB.
• When a Moderator reports a Topic, the UI is not updated instantly with Moderator action elements.
• When a User reports a Topic, we show no "Thanks for reporting" message. We MAY want to add that. We do say thanks in e-mail IF the User has e-mail address in the profile. IF we add "Thanks" to the UI, we MAY want to show Report ID to refer to when contacting customer support.

[tiblu]

Citizen OS deployment notes:

• PROD DB backup before update - b1242
• PROD API release version in Heroku - v494
• PROD FE release version in Heroku - v377

[oksks]

Just arrived here, as I went through the Report Topic flow (for Crowdin screenshots) and it's really weird to go through a proper flow, click the "YES I'M ABSOLUTELY SURE" (or something) in the "Are you sure you want to report this topic?" window, and then have everything disappear without any confirmation that I've actually gone through it successfully.

Pretty please add a confirmation - maybe even pin a red notification to the topic's heading, that "You've reported this topic on DD.MM.YYYY".

[KatiVellak]

Legally reviewed, during the discussions legal input provided.