Currently, if Discourse is configured to require approval of posts unless the user has a certain trust level, those pending posts are not visible to their authors.
I’m tasked with migrating an existing forum from another platform where this works differently, and one of the requirements is to preserve the old system’s behavior in this respect.
So, my goal is to make it such that when a “not fully trusted” user posts a reply or starts a new topic, the message is queued for approval and yet is immediately visible to its author, as if it has already been approved, while no other users (except for moderators) are able to see this post.
I’m only beginning to hack on Discourse, finding my way around the code. Can someone more experienced please point me in the right direction on how best to implement this?
An engineer who works with me has implemented this feature and we are now testing it locally. We would like to contribute it to the core. Is the @team interested in a PR with this functionality? It would require some additional effort on our part to clean the code up for contributing, so I’d like to understand whether it makes sense and actually welcome.
Sure! As long as it doesn’t introduce any regressions or new dependencies, we generally accept PRs like this. We’d like screenshots of the UI included so it’s clear what’s happening, of course.
I recently tested the New member post queue and found the “Your post awaits approval” modal a bit off-putting.
And this was on localhost when I expected it to happen.
What was most disconcerting was that not being able to see the post, there was no visual confirmation of success.
I don’t know if being able to see the post would be all that much better as it would send a big “we don’t trust you yet” message to the New member either way.
I would hope most would understand it to be a general anti-SPAM measure but n any case, I do think allowing the member to see their post with a type of greyed out overlay would be an improvement.
In our implementation, we’ve gotten rid of the “Your post awaits approval” message and other than that there are no UI changes. (Well, there is a site setting that enables the feature.)
So, for the author of the post everything works as if his post was not held for moderation. No graying out or anything like that. Just as if the post was published as usual. All the other users, though, only see the post, and are notified of it, when a moderator approves the post.
The moderation process works through the existing Queued Posts mechanism; no changes there.
Thanks, @codinghorror, we’ll make sure all the tests pass and submit a PR.
No, I think what he’s saying is that there must be UI visible to the user that clearly identifies the reply as “Not Yet Approved”. So I suggest adding this to the post somehow.
A hellbanned user is invisible to all other users, but crucially, not himself. From their perspective, they are participating normally in the community but nobody ever responds to them.
This sounds like a candidate for a site setting to me. Or, if @codinghorror doesn’t like that: Posts showing up in the stream with a “not-yet-approved”-marker is definitely a core feature, and then a (likely very small) plugin can hide that marker.
I guess most often New members would never become aware that their post was only visible to them until it was approved.
And believing everything went OK would be help give a more “friendly” feeling. But if it were me, I’d rather have honesty. Some type of
Welcome to the forum and thanks for posting!
To help keep our site free of SPAM your post is temporarily visible only to you. Please understand this is nothing personal, and applies to all new members.
If I learned that I had been misled it would bother me more than something like that message.
But I may be the odd man out here.
Someone can insult me to my face and still have my respect, but if they talk behind my back I’m offended.
I agree that there are drawbacks to this behavior and I won’t advocate to make it the default mode of operation.
In our forum, we’ve used it for about 4 months now and are generally happy with the results. We had actually changed it from the explicit “Your post is awaiting moderation” message and observed a clear drop in the number of complaints related to the posts’ being held for moderation.
I just took a quick look at this PR and have a few concerns. It’s possible I’ve misunderstood how the code works so I’d appreciate any corrections
It seems like when this feature is enabled, the post is inserted into the topic right away as opposed to the queuing table. A separate table queued_preview_post_maps is used to keep track of posts that are currently queued in this way.
I can think of a couple major downsides to this:
This means the hide_queued_preview scope has to be added in every place a user might be able to see another user’s post. This kind of thing is quite easy to forget when someone adds any new code that fetches posts.
There are serious performance considerations. We have to join an extra table for every query for a post wouldn’t we? This seems to be true even if the feature is disabled? Additionally the new table doesn’t have any indexes right now which is a performance time bomb.
If a user makes a post mid topic, say post 50, then 20 other people make posts and many readers follow along, what happens when the post is approved? Won’t all the readers who read past it have missed the post? It seems to me it would leave a gap in their topic.
I don’t think we could accept it without work to address these issues.
Robin, thanks for the review and feedback! I’m sure your comments will help us improve this feature.
Correct. The post is inserted into the topic right away and also added to the queuing table. queued_preview_post_map links the pending posts in the posts table and the queuing table.
Agreed.
This definitely shouldn’t be the case if the feature is disabled. When it is enabled, an extra join is taking place indeed.
Good point! We need to add an index.
The readers who are watching this topic will still receive a notification, but if they have read past that post number, the topic will not be listed as unread for them and the post won’t be marked as unread.
I guess the use of this feature in its current form only makes sense when these situations (many approved posts appearing after an unapproved one that is approved later) are expected to be rare due to how the forum is administered. In our case, the forum is basically pre-moderated. Only TL3+ users post freely. There is always a moderator online and we’ve implemented browser notifications for the queued posts. So any action on pending posts is taken quickly.
What specific design or implementation changes do you recommend?
Ah, I see, my bad! That’s good that the join is not included when disabled.
This is my main objections to this approach. If the forum isn’t administered quickly those posts will most likely be ignored. We purposely did not implement queued posts in this way for this reason. I worry that if we merge this in, and people turn on the option, it will lead to much confusion as posts are missed.
What about giving the author some type of view of the post moderation queue (essentially a read-only view of the admin’s to-be-moderated list, filtered by only their own posts)?
What if we make this feature dependent on the site setting “approve unless trust level = 3”? And also explain in bold letters the consequences?
Or, can you suggest an alternative design for this feature that would address the missing posts issue?
As a general comment, if a forum requires pre-approval of some posts and those queued posts are not administered quickly, it is going to create complaints in the community regardless of this feature.
This wouldn’t work for us, as the explicit requirement is to make the pre-moderation “invisible” to the participants to as much extent as possible.
