Make Pending option from Topic Actions wrench

I’m interested in having an additional option placed within the Topic Actions “wrench”. Specifically, the option to change the Topic’s Status to Pending (Make Pending let’s say).

The primary use case would be when a Topic contains content that is questionable for whatever reason, and a bit more thought needs to be put into how to best treat it. Clicking the wrench and making it Pending status seems like the most efficient method, but of course I’m open for other thoughts.


I’m not following. Why not set a bookmark timer on the first post?

What he wants is to make some topics/posts hidden as if they were caught by the watched words trigger. He wants the post not to be visible to users but go into the review queue for later handling (e.g., contact the user about the post and why it is innappropriate).

1 Like

Wait, so we’re talking about posts that are in already the review queue? Or forcing existing posts into the review queue?

That’s an interesting idea…

Forcing existing posts into the review queue.

@pfaffman That’s correct.

@codinghorror anything else I can offer up?

I think this is a good idea, no idea how hard it is from an implementation perspective. What do you think @sam?

If there are no replies I guess it would be not too hard… @eviltrout or @Roman_Rizzi probably know exactly how involved it would get.

I think once we move it to pending we would have to possibly hard delete the topic and move to another table.

1 Like

I think any post should work, topic is a bit of a special case… just pretend this post said a naughty word… wrench it and force it into review queue?

1 Like

Yeah any single post should be easy-ish (sequencing will go off, but is could possibly work), where it gets very complicated is trying to do an entire topic that got replies.

Not sure how much of a use case it is? Appears to be so from the OP.

Jane creates topic: I like eating marshmallow
Jim replies: Don’t you know … this site is about “not marshmallow”

Site is about candy, but site operators do not like marshmallow, it is 5am … they can not deal with this.

Click button … back to approval queue on Jane’s topic. We can deal with this tomorrow.

Problem is … how do we deal with this? What happens with timestamps when we repost and so on. Review queue does not support multiple posts in a chunk.

I would say the current “supported way” of dealing with this is.

  • “Make unlisted”
  • Flag for moderator attention so nobody forgets about it

Downside is that people can still see it if they have the URL.

Other option may be: “hit delete”, flag the deleted content (not sure if reviewable supports this, but maybe it is reasonable to allow moderators to flag deleted content)


Yeah a big difference is that queueing a topic before it’s created is much simpler than afterwards.

Still, we do have support for hiding until dealt with in the queue. @Roman_Rizzi can estimate this when he’s back next week.

1 Like

@ked does this work for you? Have you tried the above? :point_up_2:

Yes, I’ve tried and understand. It’s not ideal, but workable I guess, given the other constraints/related issues I see discussed above.

My primary use case is when a Topic gets created and displayed, that I’d rather have been caught within the Watched Words feature. Mostly I observe these within let’s say an hour, and they often don’t have a first reply yet. An workable idea might be to have a “Make Pending” option available in the wrench only for those Topics which do not yet have a first reply? Just a thought.

Regardless, I’ll use the Make Unlisted routine if nothing else develops on this.

Thanks for the look on the matter.


Sorry for the delay. I’ve been thinking quite a bit about this.

Making a post pending means hard-deleting the post and storing all the necessary data to re-create it inside the reviewable’s payload attribute. I had to rewrite this a couple of times because I was worried about losing data in this transition due to associations tagged with dependent: :destroy or dependent: :delete_all. However, after some testing, I believe it should be safe to do so.

Doing this when a topic has no replies or when it’s not the first post should require a low to moderate effort. All the logic for queueing a post is inside the NewPostManager#enqueue method, so we’ll have to extract it into a separate class and re-use it. We always add pending posts at the end of the topic after approval, so adding them in a specific position will require a little more work.

Moving a topic with replies back to pending should be more complicated using this approach. Serializing it into a reviewable seems a bit too much. Maybe we could temporarily hide the topic instead? For example, we already do this when a post gets flagged by spam by a trusted user.

Alternatively, we could always flag + delete (or hide) instead, making everything a lot easier. I can’t think of a reason why hard-deleting and queueing the post is better.


I forgot to post an update here. We added a Flag Post button in the flag modal, next to Take Action.... Clicking the post sends the post to the queue and hides it, then a message is sent to the user to let them know that it’ll remain this way until a staff member reviews it.

1 Like

Thank you @Roman_Rizzi


I think we need to review the wording here:

It is very confusing what to pick.

Maybe change the words “Flag Post” to “Add to Review Queue” with perhaps a different icon.

Having 2 buttons called “Flag Post” is very confusing.