Improving Blocked User State

Continuing the discussion from Description of various user states in Discourse:

Has there been any thought about a second type of staff initiated suspension? Right now, a user is either “normal”, blocked (which I believe cannot be done manually), or suspended. Suspension does not allow the user to log in, and thus also prevents communication with the user, even by mods/admins over PM. It would be helpful to have a method to “partially-suspend” a user where they can log in, but cannot make any topics or posts, except in a PM with staff. This way mods/admins can talk to the user about what is going on, while still preventing them from making new posts that could cause issues.

I have 2 examples of where this could be useful.

The first example did happen about a month ago. A new user created an account with a completely inappropriate username (it included a swear). We (the mods) sent an “official warning” PM asking the user to change their name before posting, or we would be forced to suspend their account. We would have liked a method to temporarily block public posting so we could discuss the new name. Fortunately, the user sent an appropriate name before making any posts, we changed it and had no issues. However, had the user posted, we would have suspended the account and thus have had no method to communicate further.

The second example has not happened on a site I moderate, but I have heard of it from a friend. Let’s say a user starts creating creating controversial posts. They might fall into a “grey area” of the rules, and thus not be 100% clear that they are violating anything. The mods PM this user to explain the situation (whatever the issue might be), and feel that an understanding is reached. However, the user posts something controversial again. The mods have now received many reports (this wasn’t a Discourse site, so no flags) about the content, and don’t want the user posting anything else until they are sure there is an understanding. If this was to happen on a Discourse site, the mods would not have many options here, as they would either have to watch for new posts by the user and delete them while discussing things, or suspend the user and lose the ability to communicate further.

Both of these situations are ones where suspension might be too harsh, and communication (discourse!) is what is necessary. In both of these, suspension might have been warranted if the user appeared to be doing things on purpose, but in many cases there is a lack of understanding, a maturity difference (we have lots of younger users on our site), or a language barrier. In the first case, the “partial-suspension” is preemptive, making sure the change is made before any posts happen, in the second, it would be reactive, helping to prevent further issues. In both cases, I think it would be a useful tool for moderators to have.


This is not totally correct. PMs to suspended users from staff are still delivered via email. That is a one way conversation though, mostly intended for “here’s a larger 3 paragraph reason why you are suspended, bye”.

We could also make blocked a more toggle-able state, I have mentioned a few times we should improve blocked to make it more useful in more circumstances.


Oh, sorry. I did not mean to misrepresent anything.

And there is the problem. one way. To me, it goes against a lot of what Discourse is all about.

OK, so the current description of blocked is:

If I understand Discourse correctly, a PM is just like any other topic except it is restricted as to who can view it. If so, would blocking accomplish what I am looking for here (as it currently exists)?


I am definitely open to improving the blocked state so it is more generally useful…

@neil can you add this to your todo list? I do think this state can be more useful if we enhance it a bit.


Saw that this was added to the Discourse Version 1.5 #releases topic, however it was listed as

Is the intention to limit this feature to admins only, or will this be an option for moderators as well?

1 Like

I think moderators should be able to do this. If they can suspend people, they should be able to block too.


I added this feature today. Enjoy!


@neil, glad to see this feature added, it should be very helpful for us!

Just did some testing over at the Stonehearth Discourse and I would like to share my thoughts. First, I think the UI changes when looking at Latest and individual topics is great! The New Topic and reply buttons are gone, and it is nice and clean. The “you have been blocked” PM is also great, and I am glad a similar “you have been unblocked” message was also received. However, I did encounter some issues when it came to PM.

First, the New Message button was still on the PM screen, but after composing and attempting to send a PM, I received the following message:
Something has gone wrong. Perhaps this topic was closed or deleted while you were looking at it?. Additionally, there was no option to respond to PMs, even the PM automatically sent from the system user. In order to make blocking really function well, I think that the user needs the ability to (at minimum) reply to the auto PM (which would need to come from @moderators instead of the system user), if not be able to create PMs to staff. To work for our 2 use cases above, the ability for staff to communicate (both ways) with the blocked user is crucial.


Ok, will look into those bugs next. Blocking has always behaved that way, so I guess no one cared about blocking until now. :open_mouth:


I think the reason “no one cared” was because we (mods and admins) couldn’t control when someone was blocked. It was always automatic, and once we resolved the thing that blocked them (post needing approval, spam, etc.) that was the end of it. Now that we can use blocking as a moderation tool, (and thus can actually test how blocking works) I think we will find more bugs…sorry! :frowning:


It’s fine, we want blocked state to be more useful, so these are good changes. Feel free to work them up and @neil will slowly improvinate it!

1 Like

“improvinate”…that’s a new word for me :smiley:! Do you want discussion to continue here, or would you like reports in the #bug category as we continue to test this?

I don’t think a bunch of topics would help, probably just replies here is fine.

1 Like

I pushed the fixes today. The buttons to create private messages and replies will only show up when the blocked user has permission. Blocked users can send and reply to pm’s with staff.


Hey @neil, thanks for the fixes! I am happy to confirm that everything seems to be working as it should with PMs. The corner case of a multi-user PM to some staff and some regular users was covered as well.

Unfortunately, I have found a few more bugs…

  1. When attempting to message a non-staff member, the following pop-up is received.
    It is not exactly descriptive, and doesn’t explain to the user that due to being blocked, they can only message staff.
  2. The @moderators group cannot be PM’d. The following error is received:
    I believe that if a site has set up @moderators or @admins to be able to receive PMs from users, this should work. At minimum, if group PMs even to staff are restricted from blocked users, the error message needs to be more descriptive.


  1. Yeah I encountered the “Topic can’t be blank” modal while working on this too. It’s a bug in another area of the code that has been there for a while. The HasErrors module is broken.
  2. Will look into that one.
1 Like

Hey @neil, hoping to check on the progress of the blocked users PM fixes. We’ve used this feature a few times at Stonehearth, and it concerns me that a user really has no way of knowing why the PMs are failing.

I also sent a PR to update the automated account blocked PM as it doesn’t currently tell a user what “blocked” means.


So The Travis CI build failed for my PR. Never done this before, so I am really not sure what this means, or how to fix it. Any help would be appreciated.

Edit: @codinghorror merged the PR, could you explain what the Travis CI is, and (more importantly) why the failure didn’t matter?

Travis fails a lot. I dunno, it has cry wolf syndrome. In this case where you only made a copyedit, there’s almost no way that could fail the build or tests…


It has been a much bigger problem lately. It fails quite often. We should investigate as it it’s a useful service but quite annoying with false negatives.