Reasons a post was flagged as abusive?

We provide an option when reporting abuse to specify an AbuseReasonId (default = 0), which is then included with the report when referenced elsewhere. Both the specifying and interpreting of this reasonId would be a customization.

All API types support this, here is the REST endpoint:  Create Abuse Report REST Endpoint  

Steven Heffner said:

All API types support this, here is the REST endpoint

At which point is something a "you should do this via your own customisation / our customisation services" vs "we will include it in a future release" ? Clarity on this would be helpful and ease frustration.

Steven Heffner said:

We provide an option when reporting abuse to specify an AbuseReasonId

But that isn't in the platform user interface by default for some reason?

While this could be added via a customization, I agree that this should be reviewed/discussed as a platform change. This is currently in the product ideation here:  Enable users to include a short message when reporting abusive content or members  

Ben Tiedt said:

This is currently in the product ideation here:  Enable users to include a short message when reporting abusive content or members 

I'm aware, I commented on it 4+ months ago.

Didn't quite answer my question though.

I apologize. Let me attempt again.

Christopher G. Stanton said:

But that isn't in the platform user interface by default for some reason?

The functionality was originally in the platform to inquire about a reason for abuse at the time the report is filed and, based on feedback, it was simplified to a single action while leaving the API for backwards compatibility or customization. At the time, the feedback we received was that the two step process was cumbersome and unneccessary.

Christopher G. Stanton said:

At which point is something a "you should do this via your own customisation / our customisation services" vs "we will include it in a future release" ? Clarity on this would be helpful and ease frustration.

Over the history of the Community platform, there have been a few features that have flipped back and forth (often related to SEO as recommendations changed, but also user-related features that have gone in and out of favor over time). This feature was one that is being requested to be restored by feedback after being asked to be removed by feedback. That's not a bad thing and expectations and use-cases change over time. The goal of the platform is to provide a successful initial experience for the majority of users. When a feature request/change has significant support, it is considered to be included in the product by default.

Specifically to address when should a feature be custom vs. included in the product:

• It should likely be custom if it is not a generally beneficial feature. We gauge this by market review and the ideation.
• It should likely be custom if it is needed sooner than it will be included in the platform if it is scheduled to be included in the platform by default.
• It should likely be included in the platform if it is requested by a significant number of existing customers and/or is a market/strategic direction.

Hi Ben, 
Thanks for the explanation, didn't know the functionality was there in the past, interesting .

I think a lot of people working with the platform are requesting to be able to add a reason when flagging a post/reply/user etc as abusive. Speaking to some of them they would really like to see this functionality (back again). Might be a nice feature to bring back in on a future release!

Ben Tiedt said:

It should likely be custom if it is needed sooner than it will be included in the platform if it is scheduled to be included in the platform by default.

This is the crux point here that I believe needs more transparency so the decision can be made.

If I look through the ideation, I can see ideas that have been there for 3+ years, some have votes of over 50, some have votes of over 10. Some have been pointed out that the votes are mainly from the same company, but others have not got this breakdown.

A decision to go for making something custom can't be made if it isn't clear what the timeline is for the decision on it to be made, and it isn't clear how ideation is prioritised when the evidence is that they're sat there for so long, and presumably over time customers will come and go which would muddy that further.

There needs to be better action and clarity of whether the person posting the ideation should consider going the custom route without the alternate silence of waiting for ideation resolution.

Anyone had any luck getting anything done? This is driving us nuts! We were receiving upwards of 10 reports a day (we used to get one every few months on our old platform!!). We have tried everything. We asked people why they were reporting posts but the only thing we concluded was that the reply and report buttons were too close together and people were accidentally pressing it so we had some work done to move the report link to the far right of the post. It has made no difference. Moderators are tearing their hair out. We discussed it again today and have we are convinced that this problem could be solved if there were a two step process, i.e click the link then complete the short message to give a reason why you are reporting something. This at least gives people time to decide that they didn't mean to report it in the first place.  I posted on an idea thread a year ago and the problem is just getting worse. We never had this problem on our old platform which had the two step process, so it is very obvious  that this is just not good design.

 Sarah Wilson One possible area to check is the email notifications. If you look at an email from this site, the link is easily accessible, but also somewhat downplayed:

For my site, we have it displayed like this: 

Does the link happen to be very prominent on your notifications? 

Alternatively, you said

Sarah Wilson said:

accidentally pressing it so we had some work done to move the report link to the far right of the post.

On the actual widgets, you could rearrange the order of the options. Without looking deeper, and depending on your comfort level with changes like this, it looks like this can be rearranged in Widget Studio on Forum - Thread / content-thread-start.vm from around lines 217-295 (there might be more places that need changes, that was just a quick glance). You can also change the text for that button in the Language Resources on that same widget if that possibly helps.