Hi Eva, I went over your code and there’s no errors that I can spot - and I totally get your frustration. If it hadn’t been for Simon Cossar I don’t know how I’d have resolved it myself.
So, taking it backwards: if the PHP is correct, then something else must be disconnected. (browniepoints for me, yay.)
But…
I don’t know enough about any of that to be able to give suggestions or help.
If you’ve got your forum parked with the boys from Discourse Hosting, you could ask Richard (his name tag won’t pop, but this is his profile: Profile - RGJ - Discourse Meta )
Or perhaps @simon might be able to provide you with the missing steps.
Keeping my fingers crossed for you.
edit:
p.s. these are all the related plug-ins i use (+ that PHP one)
(Memberpress Drip is email marketing, so not related to this)
groups are any and all: closed and opened (i don’t give access to hidden groups, come to think of it)
these are some of the group names as displayed in ‘Groups’ - and as you can see, the “NoSpacesNames” are the ones that coincide with the PHP settings
If by parameters you mean the following, then no:
nor in the actual group settings (where you create it, with name, owner, etc.), it’s all straight forward and not connected to accessing through SSO - so setting or not setting this as a person’s primary group is not relavant.
There is one webhook here on Discourse that I put in as instructed by the WP-Discourse plugin:
email verification technically goes via memberpress: they (my wp-instance) send the log-in details to the user. by clicking the log-in link the users verify their address.
i know for a fact that it’s not through Discourse, because for a while it ALSO went through discourse (glitch somewhere) and Richard sorted that for me.
¿Es posible con este método asignar a los miembros el nivel de confianza 2 en Discourse cuando abren una cuenta pagando, y reducirlo al nivel de confianza 1 si no pagan mensualmente?
No lo he revisado en un tiempo, pero lo que necesitarías es una comunicación entre tu código de Discourse y tu código de pagos (en mi caso: MemberPress).
Así que si la persona deja de pagar, MemberPress cambia su código, y este código corresponde a un nivel de grupo diferente.
Si no hay conexión con el pago, el nivel de grupo no se ajustará.
Ah. Espera.
Volví a leer tu pregunta: no estoy seguro de cómo funciona con los niveles de confianza…
pero… si todo lo demás falla, puedes crear fácilmente un GRUPO configurado con nivel de confianza 2 y otro con nivel de confianza 1, y hacer que tu plugin de membresía asigne esos grupos a tus miembros.
Espero que esto ayude. Si no, tendré que volver a profundizar en el tema. Ha estado funcionando desde la conversación anterior y no lo he revisado desde entonces.
Esto surgió en otra publicación en Meta hoy, así que revisé el código para confirmar si el nivel de confianza de un usuario puede reducirse al añadirlo a un grupo que establece un nivel de confianza inferior al del grupo actual del usuario. Al examinar el código, veo que esto no es posible:
def grant
if @user.trust_level < @trust_level
@user.change_trust_level!(@trust_level)
@user.save!
end
end
Si el nivel de confianza de un usuario es inferior al nivel de confianza que otorga el grupo, añadir al usuario al grupo actualizará su nivel de confianza. De lo contrario, no habrá ningún cambio en el nivel de confianza del usuario.
Estoy un poco oxidado (además, es tarde), pero el nivel de confianza realmente no sería relevante. No uso niveles de confianza en absoluto. El Grupo TL 2 tiene acceso a ‘esto’ y el Grupo TL 1 no.
El nivel de confianza real no está en uso. Cualquier miembro puede tener un nivel de confianza 1 y aún así obtener acceso (mediante pago) al Grupo TL 4, siempre que no configure permisos por niveles de confianza, sino solo por grupos.
@Dani1, gracias por compartir tus experiencias y dificultades aquí; es de gran ayuda para otros que, como yo, utilizan MemberPress.
Eso tiene sentido, pero me pregunto qué sucede si la suscripción del miembro expira y nunca cierra sesión, por lo que sigue accediendo al grupo… ¿Has encontrado que esto sea un problema?
De ser así, me pregunto si hay una manera de forzar una actualización o un cierre de sesión…
@RGJ El código anterior marcado como solución sí elimina a los miembros de los grupos, pero como mencionó Dani1, dijo que no entra en vigor hasta que se desconectan.
Si un usuario se actualiza a través del proceso normal de inicio de sesión SSO, la actualización no se producirá hasta que se cierre la sesión y vuelva a iniciar sesión. El ejemplo de código anterior es la forma más sencilla de abordar el problema, pero probablemente no sea la mejor manera de gestionar la membresía de grupos.
El plugin WP Discourse tiene varias funciones de ayuda que se habilitan cuando WordPress funciona como el sitio proveedor de SSO para Discourse. Estas funciones permiten actualizar las membresías de grupos sin que el usuario tenga que cerrar la sesión en Discourse. Esas funciones se encuentran en el tema al que Richard enlazó: Manage group membership in Discourse with WP Discourse SSO.
La publicación a la que Richard enlazó proporciona algunos detalles sobre los dos enfoques diferentes. Voy a añadir esos detalles al tema howto la próxima semana. Por ahora, sería bueno leer la publicación.
(Obviamente, todo eso es muy manual. Solo tengo un puñado de personas y sé exactamente lo que está haciendo cada una. Aún no he probado la solución de Richard, pero es bueno saber que existe).
¿Podrías añadir un enlace aquí cuando eso suceda? ¡Gracias!
Claro, el tema está aquí: Manage group membership in Discourse with WP Discourse SSO. Describe cómo utilizar las funciones add_user_to_discourse_group y remove_user_from_discourse_group de WP Discourse. Asumiendo que tu sitio de WordPress está configurado como el sitio proveedor de SSO para Discourse, esas son las funciones que debes usar para gestionar las membresías de grupo en Discourse.
El ejemplo que usa ese tema es con el plugin PaidMembershipsPro, pero un enfoque similar debería funcionar con cualquier plugin de membresía de WordPress bien desarrollado.
Voy a agregar algunos detalles al tema sobre cómo gestionar la membresía de grupo con los parámetros de SSO add_groups y remove_groups. Para la mayoría de los casos, gestionar la membresía de grupo añadiendo esos parámetros al payload de SSO no será el mejor enfoque, ya que requiere que los usuarios se desconecten y vuelvan a iniciar sesión en Discourse antes de que se actualice su membresía de grupo.
Mi esperanza es que en un futuro cercano haya una solución lista para usar para vincular Discourse con plugins específicos de membresía de WordPress. Actualmente, esto solo se puede hacer añadiendo una pequeña cantidad de código personalizado a tu sitio de WordPress. Si esto no es algo que sueles hacer, es posible que necesites contratar a un desarrollador para que te ayude con esto.
Gracias por los detalles. Veré si puedo meterlos en mi cabeza.
Estoy de acuerdo: prefiero que la adición/resta de grupos se haga al momento, en lugar de esperar a que el usuario cierre sesión y vuelva a iniciarla.
Si no logro solucionarlo, contrataré a un desarrollador aquí para que lo haga y compartiré el código. Creo que hay un par de personas que ya lo han hecho en la sección del mercado.
