What am I missing here? Just had a user log on for the first time through WordPress SSO. I have configured such that approvals are required. Shouldn’t that option appear here? I have no idea how to approve this user 
I do have the notification in the admin menu that there is a user awaiting approval.
I can reproduce this issue if I enable both SSO and the must approve users site setting. To approve the user, click on their username in the review item:
This will take you to the user’s admin page:
In the Permissions section of the user’s admin page, click the Activate Account button if the user has not yet been activated:
Then click the Approve button:
This should approve the user and clear the notification from your Review Queue.
Cool. That’s fixed, with thanks. So is this by design? I’m not sure I understand how the concept of activation fits in here. Do I need to both activate and approve every time?
I think that having both SSO and must approve users enabled is a bit of an edge case. I’m not sure how it is expected to work. Ideally, when SSO is enabled, you would handle user approval on the SSO provider site (WordPress.) Unfortunatly, this requires some custom code. See How to prevent some WP users from being able to login to Discourse for details about setting that up.
I am going to look into how user approval is expected to work when both must approve users and SSO are enabled. I’ll report back here if I find anything worth noting.
Thank you for the excellent response, @simon. I didn’t mention this earlier because it was merely based on a recollection (which, in my case, is always suspect). But…
I just had another user sign in and I immediately had the approval option available i.e. no need to go through the activate stage first.
So this remains pretty confusing to me. I haven’t made any configuration change that would explain why the process was different between the two most recent new folks. Confusion reins…
I will let you know if I discover more.
Thanks again.
I thought that it wasn’t allowed. The SSO host is responsible for managing users. My understanding is that If you need some users who have accounts on sso not to have access to discourse then you need to manage it with groups or somehow deny login to discourse.
Although we have the weirdness with having to both activate AND approve some users after they try to log on. it does seem to be working. With the settings we have, the admin has to approve requests after each user tries to log for the first time. That is fine (kinda - see below), so the two settings (use SSO and approve users) seems to be OK.
That said, the inability to pre-approve a set of users, before the user makes that first log on attempt, is unfortunate and quite a problem. That means the user has a wait before they can log on, even though we (admins) are perfectly aware of who they are ahead of time.
I suspect @simon is correct about this being an edge case from a Discourse perspective. However. it’s pretty common for WooCommerce sites to sell both regular products and memberships. I am in that situation and it’s a pretty common scenario. So my users are split into two (and overlapping) logical sets - customers and members. I want to be able to pre-approve the list of members so they don’t have to wait for approval. I may look at automating this later but it will have to be after my forum launch on September 1st, which is a shame.
Aha! You want to configure woocommerce to manage those groups in discourse, not manually fuss with those users in discourse. There are some topics about doing that. It takes a bit of custom code, and some examples are available. For a frame of reference, I typically charge $1000 to $1500 for that.
Thanks @pfaffman. I can probably do this myself with time and have been researching. For launch, I’m going to set an expectation that an approval will be required and just try to address those quickly. After launch I will see if I can automate this in some way.
A clarification in one thing about my hopes for the fully automated solution.
I want to avoid a solution where non-members can actually logon but are then blocked from doing anything (perhaps because they are not in some members-related group). Instead, if they are not a member I want their actual logon to fail, preferably with some ability to redirect to a page, where I can explain why.
Put another way, block-from-logon-if-not-a-member is preferred over allowing logon but then blocking access to resources.
Thanks again.
@simon I just took a few minutes to research possible options to this challenge - and stumbled across you on this page 
WP Discourse – WordPress plugin | WordPress.org. So, I do have a more directed question for you about the plugin.
My business resolves around WordPress / WooCommerce and all my integrations tend to use tags, where they can, to manage users. WP Fusion is the glue that brings all this together but the bottom line is that I have tags on all users (whether customers, members, etc).
With that context, what I would love to be able to do is write my own function on the WordPress side that implements some logic (in my case, as simple as checking for a tag on the user) and rejects the logon if that criteria is not met.
Off the top of your head, do you know if there is any hook I can user that would allow me to implement that logic? That would be an awesome solution and leaves the logon still very much in the hands of WordPress.
Thank you.
Yes, this topic describes how to do what you are looking to do: How to prevent some WP users from being able to login to Discourse. The second post in the topic has two example functions that you can use. You will need to supply the code to replace the /* Some condition that returns true if the user doesn't meet the membership requirement */ comment that is in the code example.
Fantastic!! I think I misinterpreted that topic when I browsed it earlier but it looks to be exactly what I need. Pending implementation and testing (famous last words!) I think I am set!
Thank you.
I figured. . . and . . .
Told ya so! 
Glad you’re well on your way to getting it sorted.
Indeed. My apologies for missing that, @pfaffman and thank you for your help. I am off to set up a mirrored Discourse VPS to talk to my mirrored web site and, all being well, hope to have this up and running soon.
