Qu’est-ce que je rate ici ? Un utilisateur vient de se connecter pour la première fois via l’authentification unique (SSO) de WordPress. J’ai configuré le système de manière à ce que des approbations soient requises. Cette option ne devrait-elle pas apparaître ici ? Je ne sais absolument pas comment approuver cet utilisateur 
J’ai bien la notification dans le menu d’administration indiquant qu’un utilisateur est en attente d’approbation.
Je peux reproduire ce problème si j’active à la fois le SSO et le paramètre du site must approve users. Pour approuver l’utilisateur, cliquez sur son nom d’utilisateur dans l’élément de revue :
Cela vous mènera à la page d’administration de l’utilisateur :
Dans la section Permissions de la page d’administration de l’utilisateur, cliquez sur le bouton Activer le compte si l’utilisateur n’a pas encore été activé :
Ensuite, cliquez sur le bouton Approuver :
Cela devrait approuver l’utilisateur et supprimer la notification de votre file d’attente de revue.
Cool. C’est réglé, merci. Alors, est-ce prévu ainsi ? Je ne suis pas sûr de comprendre comment le concept d’activation s’insère ici. Dois-je à la fois activer et approuver à chaque fois ?
Je pense que l’activation simultanée de l’authentification unique (SSO) et de l’option « doit approuver les utilisateurs » constitue un cas d’usage assez marginal. Je ne suis pas certain de la manière dont cela est censé fonctionner. Idéalement, lorsque le SSO est activé, vous devriez gérer l’approbation des utilisateurs sur le site du fournisseur SSO (WordPress). Malheureusement, cela nécessite du code personnalisé. Consultez How to prevent some WP users from being able to login to Discourse pour les détails sur la configuration de cela.
Je vais examiner comment l’approbation des utilisateurs est censée fonctionner lorsque les options « doit approuver les utilisateurs » et le SSO sont toutes deux activées. Je reviendrai ici si je découvre quelque chose d’intéressant à noter.
Merci pour votre excellente réponse, @simon. Je n’avais pas mentionné cela plus tôt car cela reposait uniquement sur un souvenir (qui, dans mon cas, est toujours suspect). Mais…
Je viens d’avoir un nouvel utilisateur qui s’est connecté, et l’option d’approbation était immédiatement disponible, c’est-à-dire sans avoir à passer par l’étape d’activation au préalable.
Cela reste donc assez déroutant pour moi. Je n’ai effectué aucun changement de configuration qui pourrait expliquer pourquoi le processus a été différent entre les deux derniers nouveaux arrivants. La confusion règne…
Je vous tiendrai informé si je découvre davantage.
Merci encore.
Je pensais que ce n’était pas autorisé. L’hôte SSO est responsable de la gestion des utilisateurs. Ma compréhension est que si vous avez besoin que certains utilisateurs ayant un compte SSO n’aient pas accès à Discourse, vous devez gérer cela via des groupes ou d’une manière ou d’une autre refuser la connexion à Discourse.
Bien que nous ayons cette bizarrerie consistant à devoir à la fois activer ET approuver certains utilisateurs après qu’ils aient tenté de se connecter, cela semble fonctionner. Avec les paramètres que nous avons configurés, l’administrateur doit approuver les demandes chaque fois qu’un utilisateur tente de se connecter pour la première fois. Cela convient (en quelque sorte — voir ci-dessous), de sorte que les deux paramètres (utiliser SSO et approuver les utilisateurs) semblent corrects.
Cela dit, l’incapacité d’approuver à l’avance un ensemble d’utilisateurs, avant que ceux-ci ne tentent leur première connexion, est regrettable et constitue un véritable problème. Cela signifie que l’utilisateur doit attendre avant de pouvoir se connecter, même si nous (les administrateurs) savons parfaitement qui ils sont à l’avance.
Je soupçonne que @simon a raison en disant qu’il s’agit d’un cas limite du point de vue de Discourse. Cependant, il est assez courant pour les sites WooCommerce de vendre à la fois des produits classiques et des abonnements. Je me trouve dans cette situation, ce qui représente un scénario assez fréquent. Ainsi, mes utilisateurs sont répartis en deux ensembles logiques (et qui se chevauchent) : les clients et les membres. Je souhaite pouvoir pré-approuver la liste des membres afin qu’ils n’aient pas à attendre une approbation. Je pourrai envisager d’automatiser cela plus tard, mais cela devra se faire après le lancement de mon forum le 1er septembre, ce qui est dommage.
Ah ! Vous souhaitez configurer WooCommerce pour gérer ces groupes dans Discourse, plutôt que de manipuler manuellement ces utilisateurs dans Discourse. Il existe plusieurs sujets à ce sujet. Cela nécessite un peu de code personnalisé, et des exemples sont disponibles. À titre de référence, je facture généralement entre 1 000 et 1 500 pour ce type de travail.
Merci @pfaffman. Je pourrai probablement le faire moi-même avec un peu de temps et j’ai déjà commencé mes recherches. Pour le lancement, je vais indiquer clairement qu’une approbation sera requise et je m’efforcerai de traiter ces demandes rapidement. Après le lancement, je verrai si je peux automatiser cela d’une manière ou d’une autre.
Une précision concernant mes attentes pour la solution entièrement automatisée :
Je souhaite éviter une solution où les non-membres peuvent se connecter, mais sont ensuite bloqués dans leurs actions (parce qu’ils ne font pas partie d’un groupe lié aux membres, par exemple). Au lieu de cela, si une personne n’est pas membre, je veux que sa tentative de connexion échoue directement, de préférence avec la possibilité de la rediriger vers une page où je pourrai expliquer pourquoi.
Autrement dit, je privilégie le blocage de la connexion si l’utilisateur n’est pas membre, plutôt que de permettre la connexion puis de bloquer l’accès aux ressources.
Merci encore.
@simon Je viens de prendre quelques minutes pour rechercher des options possibles face à ce défi et je suis tombé sur vous sur cette page 
WP Discourse – WordPress plugin | WordPress.org. J’ai donc une question plus précise pour vous concernant le plugin.
Mon activité tourne autour de WordPress / WooCommerce, et toutes mes intégrations utilisent, lorsqu’elles le peuvent, des balises pour gérer les utilisateurs. WP Fusion est l’élément qui relie tout cela, mais le fond du problème est que tous mes utilisateurs (qu’il s’agisse de clients, de membres, etc.) ont des balises.
Dans ce contexte, ce que j’aimerais pouvoir faire, c’est écrire ma propre fonction côté WordPress qui implémente une certaine logique (dans mon cas, aussi simple que de vérifier la présence d’une balise sur l’utilisateur) et refuse la connexion si ce critère n’est pas rempli.
Sans même y réfléchir, savez-vous s’il existe un hook que je pourrais utiliser pour implémenter cette logique ? Ce serait une solution géniale et cela laisserait la gestion de la connexion entre les mains de WordPress.
Merci.
Oui, ce sujet décrit comment réaliser ce que vous recherchez : How to prevent some WP users from being able to login to Discourse. Le deuxième message du sujet contient deux fonctions exemples que vous pouvez utiliser. Vous devrez fournir le code pour remplacer le commentaire /* Une condition quelconque qui renvoie vrai si l'utilisateur ne remplit pas l'exigence d'appartenance */ présent dans l’exemple de code.
Fantastique ! Je pense que j’avais mal interprété ce sujet lorsque je l’ai consulté plus tôt, mais il semble être exactement ce dont j’ai besoin. En attendant la mise en œuvre et les tests (les derniers mots sont fameux !), je pense que je suis prêt !
Merci.
Je m’en doutais… et…
Je te l’avais bien dit ! 
Content de voir que tu es déjà bien avancé pour régler le problème.
En effet. Mes excuses pour avoir manqué cela, @pfaffman, et merci pour votre aide. Je vais configurer un VPS Discourse en miroir pour communiquer avec mon site web en miroir et, tout se passant bien, j’espère que cela sera opérationnel bientôt.
