Thanks for the feedback @finalbarrage!
Which Discourse version are you using? I pushed a fix for this bug last Friday
Thanks for the feedback @finalbarrage!
Which Discourse version are you using? I pushed a fix for this bug last Friday
Thanks for reporting this here @finalbarrage!
@eviltrout I think I managed to find some log entries (IP’s removed):
Processing by ReviewablesController#perform as JSON
Parameters: {"version"=>"0", "reviewable_id"=>"1537", "action_id"=>"not_spam"}
Sent file /var/www/discourse/public/uploads/default/optimized/4X/3/0/6/306a2a4f7df8b151aacb933c3781cd504d751aba_2_25x25.jpeg (0.1ms)
Rendering topics/show.html.erb within layouts/application
Rendered topics/show.html.erb within layouts/application (21.3ms)
Rendered layouts/_head.html.erb (0.9ms)
Rendered common/_google_universal_analytics.html.erb (0.1ms)
Rendered common/_discourse_stylesheet.html.erb (0.2ms)
Rendered application/_header.html.erb (0.2ms)
Completed 200 OK in 227ms (Views: 28.8ms | ActiveRecord: 51.3ms)
Rendering text template
Rendered text template (0.0ms)
Completed 500 Internal Server Error in 135ms (ActiveRecord: 60.7ms)
NoMethodError (undefined method `user_id' for nil:NilClass)
/var/www/discourse/app/services/user_action_manager.rb:29:in `topic_rows'
Rendering text template
Rendered text template (0.0ms)
Started PUT "/review/1537/perform/not_spam?version=0" for xxx at 2019-04-01 13:22:08 +0000
Processing by ReviewablesController#perform as JSON
Parameters: {"version"=>"0", "reviewable_id"=>"1537", "action_id"=>"not_spam"}
Started GET "/manifest.webmanifest" for xxx at 2019-04-01 13:22:08 +0000
Processing by MetadataController#manifest as */*
Completed 200 OK in 3ms (Views: 0.1ms | ActiveRecord: 0.7ms)
Completed 500 Internal Server Error in 93ms (ActiveRecord: 25.1ms)
NoMethodError (undefined method `user_id' for nil:NilClass)
/var/www/discourse/app/services/user_action_manager.rb:29:in `topic_rows'
@Roman_Rizzi we updated last Friday around 1pm Amsterdam time - was that before you released this fix? I’ll need a bit more time to upgrade again - can try again tomorrow morning.
And yes, it would be great if you could go directly to the reported post
The fix was released around 4 PM Amsterdam time. Let me know if upgrading does not fix the issue
I have a new patch that causes flags to link directly to the post, not to the topic. I should note that the old flagging system didn’t do this, but it was a great piece of feedback!
https://github.com/discourse/discourse/commit/6470c85fda3626c5506a6a3b1d17c0483df1129e
On the imported instance (I just upgraded) there are a bunch of users (all with xxx@gplus.invalid email addresses) that have only a “reject” button (no approve button) with
system Needs Approval 6.0
must_approve_users
is not set. When I look at the user record in rails the user looks approved:
approved: true,
approved_by_id: -1,
approved_at: Fri, 29 Mar 2019 18:26:49 UTC +00:00,
previous_visit_at: nil,
I’m especially confused because there is no link to the user profile to be able to know what to do about the user. If I search for the user and find the profile, the user has a single reply, which looks fine (not flagged, etc).
Another instance that does have “must approve users” on alos has users in the queue that have only “reject” buttons and no obvious way to get information about the user (e.g., the user profile).
I’m quite confused because the users should not have been imported into the queue unless must_approve_users
was set. It’s also very confusing that you only have a Reject button. That might be because the user is not active
?
I’m confused too.
It is not set and I don’t know that it ever has been. The logs don’t show that must_approve_users
has been changed. I don’t think I ever set it from rails.
The user is active according to the user record in rails.
I just heard from another user on another site with the same problem. This site has been up for over a year. He’s got Memberful and using wp-WordPress as SSO master and 3 new users were placed in the review queue. must approve users
is not set. There is still no link to the user profile, so I don’t know how someone is supposed to decide what to do about the user. The good news is that there are both approve
and reject
buttons, so he was able to approve them.
Oh my, discourse staff has to be by far the most engaged in the industry. Never have i seen any developers being this easy to get hold of.
5 stars!
I’m experiencing the same issue as Jay, I have a queue of 11 users currently that “require approval”. We have been running Discourse for about a year and never had an issue (Thank you!) In this case the review queue was confusing because it sort of popped up after an update and our admins got very confused due tot he lack of an “approve” button. Also, 3 of the users trapped in the queue are known customers that we have communicated with via email, so we know there wasn’t any spam activity (none is shown in any logs in any case). Fortunately this seems to have only affected users since the upgrade, that is to say we have about 1500 users, and only show 11 that are currently marked as needing review, and they are all new users.
A little info:
We use the WP Discourse plugin for SSO
must approve users has never been checked
approve post count = 0
approve unless trust level = 0
approve new topics unless trust level = 0
If I can provide any additional information that would be useful please let me know, we’re not stressing too much about it at the moment, we can manually approve users if necessary for now, we’ve been so happy with our move to discourse that no one is even complaining about being asked to do a little extra work while we get this straightened out!
@Trey can you tell me if invite only
is set?
It is, in fact… I guess I assumed that if the account was created via SSO it would bypass that setting
I think the issue here is that invite only is incompatible with SSO, and before the recent update it didn’t matter.
That’s great news since we don’t need it anyway! I just turned it off along with local usernames, so SSO will be the only login method. Fingers crossed! Thanks so much!
invite only
is set on the WordPress/Memberful site. This should be turned off since membership management is handled by SSO?
EDIT: Oops. I didn’t read the rest of your post.
facing the same thing and we actually have SSO verification enabled where all our agents are automatically verified from a separate external system.
I updated this morning and think I found a regression: when filtering for any status other then ‘pending’, the server will throw a 500 error:
Processing by ReviewablesController#index as JSON
Parameters: {"min_score"=>"0", "status"=>"reviewed", "_"=>"1554192525795"}
Completed 500 Internal Server Error in 126ms (ActiveRecord: 43.3ms)
NoMethodError (undefined method `url' for nil:NilClass)```
Thanks for the report. It looks like a recent feature I added didn’t take into account that topics could be deleted. This fixes it:
https://github.com/discourse/discourse/commit/af04318afff29959cb5bb7b564d39932b0ca0557
After several reports it seems that enable sso
and invite only
is quite common in the wild, despite not being supported. This commit prevents those settings from being set at the same time, and disables invite only
for sites with SSO enabled:
https://github.com/discourse/discourse/commit/6ebadaed2c120e2bd57fe46d693cdb42eeef6e98