We made a tiny mistake on our instance where we set a user to trust level 0. This hid all of their posts… Any way to automatically unhide them now? There are thousands of posts, so doing it manually is out of the question. Thanks.
Were all the posts in categories that require > TL0 ?
I don’t think so. But the default trust level for our users is trust level one.
This is a bad idea, and I strongly advise against this. TL0 has important spam protection. You are opening yourself up to a lot of spam with TL1 default.
I just added this to the site setting description:
Default trust level (0-4) for all new users. WARNING! Changing this will put you at serious risk for spam.
That’s not the issue we’re having (nor have we had that issue in the past). We use SSO which requires a different sign up method, so we don’t get spam bots or anything. Anyway, this is a topic for another time
OK cool, with SSO enabled it is probably safe, but we have seen sites with bad login protections (no captcha, no email verification, etc) do much worse with SSO enabled. We’ve had to go back and enable many spam protections that we normally disable with SSO turned on.
Also, by the way, we tried to change that users trust level back to zero… with no change. I might just go back and change all posts  to listed if there isn’t a fix.
Okay then, put this in a psql console:
discourse=# UPDATE posts SET hidden = false, hidden_reason_id = NULL, hidden_at = NULL WHERE user_id = (SELECT id FROM users WHERE username_lower = 'fhtzoob') ; UPDATE 5000 discourse=# \q
Or, from a Rails console: (
./launcher enter app then
ActiveRecord::Base.exec_sql("UPDATE posts SET hidden = false, hidden_reason_id = NULL, hidden_at = NULL WHERE user_id = ?", User.find_by_username("fthzoob").id)
Awesome! Thank you very much
Um… not all my posts came back…
I think you’ll have to log in for the posts to update… which you can’t since your suspended.
In that case wouldn’t the procedure be to 99999 Suspend instead of dropping Trust Level below the minimum?
Yup. That’s what we did. Another admin did it because he misunderstood what it did.
@riking How about unlisting topics? Here’s my guess:
ActiveRecord::Base.exec_sql("UPDATE topics SET hidden = false, hidden_reason_id = NULL, hidden_at = NULL WHERE user_id = ?", User.find_by_username("fthzoob").id)
visible = true.
Hmm. It doesn’t like that.
PG::UndefinedColumn: ERROR: column "hidden_reason_id" of relation "topics" does not exist LINE 2: SET visible = true, hidden_reason_id = NULL, hidden_at = NUL... ^
hidden_reason_id, then got this:
PG::UndefinedColumn: ERROR: column "hidden_at" of relation "topics" does not exist LINE 2: SET visible = true, hidden_at = NULL ^
hidden_at, then got this:
PG::SyntaxError: ERROR: syntax error at or near "WHERE" LINE 3: WHERE user_id = 8048 ^
I had a similar problem. Used the following and it worked. First, entered
./launcher enter app then
rails c and then:
ActiveRecord::Base.exec_sql("UPDATE posts SET hidden = false, hidden_reason_id = NULL, hidden_at = NULL WHERE user_id = ?", User.find_by_username("USER_NAME_HERE").id)
@codinghorror this does not happen too much, but I wonder if we should have some protection here for our “hiding” code, maybe if you have more than N (100) posts don’t ever do a batch hide?
Yes that does sound like a good idea