I have our forum set to where the staff must approve all new user accounts, but the notification emails of new users are not being sent. When we first set this up, it worked fine. Now the admin no longer receives emails letting us know a new user is awaiting approval. I think the problem is that the new users aren’t being sent to “Pending”, but I don’t know why. I have to go to users -> new to find the ones that haven’t been approved. I’m also not receiving notifications of new users within Discourse.
Using WP 4.9.4 running WPLMS
WP-Discourse v1.5.8
BuddyPress v2.9.3
Thinking about it further, I think the problem is that the activation from wordpress isn’t carrying over to Discourse. If they aren’t activated in Discourse, they’re not sent to “pending”.
This is correct. They end up in the New users list. They are also never sent the activation email, so they don’t get added to the Pending users list until an admin activates their account.
I’m not sure if the Discourse ‘must approve users’ setting is intended to be used with SSO. It would be more straightforward to handle user approval on the SSO Provider end, since it’s the SSO Provider that is responsible for authentication.
The WP Discourse plugin marks all email addresses as unverified until they respond to the WordPress new_user_notification email. It does this so that unverified email addresses aren’t used to create active accounts on Discourse. If you are using the BuddyPress sign up form, then you will be creating users on WordPress with unverified email addresses. Is there anything in your signup process that verifies that a user has control over the email address they use to signup with? If there is, there are ways to hook into the WP Discourse plugin to mark the email address as verified.
Thank you for replying!
The theme we are using does use BuddyPress. The users are sent an “Activate your account” email, and need to activate their account before they can do anything.
We use the SSO Provider option and users are only created on the discourse forum if they indicate they want in (by following a link to the forum page). When they do that they are already activated in Wordpress.
I think you are saying that somehow the BuddyPress activation is not being carried over to the Discourse settings for the user in Wordpress.
I’m guessing that we can use the bp_core_activated_user hook to fix this. If this is the right path, is there a function we can hook into to make sure Discourse knows the user has been activated?
I am facing a similar issue. I have SSO enabled and “must approve users” checked, I see that the users get the notice that they will receive an email on account approval, but as an admin I do NOT get any notification when a new user is pending approval. I do not see them in the Pending tab of Users either, but they do show up as inactivated users in New tab.
What’s the rationale behind not using the same workflow for SSO + require approval setting? If there is a good one, perhaps it should be mentioned at the setting that it doesn’t work with SSO.
I would personally prefer to be notified of users pending approval.
So this changed for good once I disabled the require_activation in the SSO provider payload.
I am yet to test this, but given my setting related to approving users, I am expecting I will see a notification if there is a pending user for more than an hour.
You should see a notification if you are a moderator on the site. Admins do not get the pending user notification.
If you set the require_activation SSO parameter to true and enable the “must approve users” setting, users will not show up on the Pending list until they are manually activated by a staff member from the Admin / Users / New page.
There do seem to be some conflicts between using SSO and enabling the “must approve users” setting. Ideally, when SSO is enabled, the SSO provider site would be used to limit access to your forum. Unfortunately, this can only be done by adding some custom code to your site. There are details about how to do that in this post: How to prevent some WP users from being able to login to Discourse.
Thanks for the clarification. I noticed this discrepancy (a feature) about a year and made sure to add myself in the moderators group as well.
Understood. This is what I observed and it changed as expected after turning off require_activation but it wasn’t clear initially.
I am actually not using WP SSO, but rather a custom SSO provider that hooks up with my University’s Shibboleth deployment. We currently already limit access to a subset of University users using the custom SSO provider. But the scenario I am facing is that I would like to auto approve users who are part of a group specified in add_groups but would like to manually approve everyone else passing current filtering by the SSO provider. I tried looking up if I could pass approved: true or some such flag through the SSO API but it doesn’t seem to exist. Am I thinking it right that the way to accomplish this is by creating a custom plugin at Discourse’s end (as opposed to at the SSO provider’s code) which looks at incoming SSO request, filters over add_groups and passes approved: true while creating a new user?
I still think it might be more maintainable to handle this on the WordPress end by adding user metadata fields to indicate whether or not a user should be allowed to login to Discourse.
You’d need to find a way to reopen the match_email_or_create_user method. That method returns a User object, so you could try redefining the method in a module, and call super within the redefined method to get the User. You could then check for the value of the approved parameter or the value of the add_groups parameter, and approve users if they meet your requirements.
Yeah, that would have been ideal, but I am not using Wordpress SSO. I apologize that I chose to write about my issue here not realizing from the title the first time that this topic was tagged “wordpress”.
Thank you for pointing me to the code path that I will need to modify through the plugin. But indeed, this approach seems fairly unmaintainable as Discourse evolves. I will consider it later, if necessary.