El asistente de acceso por permisos

pom_lms_user_matches_permission_rule( string|int $rule_id ): bool

Evalúa una de las reglas de permisos del tema frente al usuario actual.

Para qué sirve

Los asistentes de acceso lo invocan internamente. Tú lo invocarías directamente para aplicar la misma regla a algo que no es un curso ni una lección —una descarga, una sección de página, un elemento de menú, un shortcode— de modo que una sola regla gobierne toda una funcionalidad de forma coherente.

if ( pom_lms_user_matches_permission_rule( $rule_id ) ) {
    // Render the members-only section.
}

Qué cuenta como «sin regla»

Un identificador de regla vacío significa sin requisito, y el asistente devuelve true.

Es la misma convención que usan los campos de curso: un curso sin regla seleccionada no queda bloqueado por el paso de regla. Tenlo presente al pasar un valor que pueda estar vacío: una opción sin establecer concede acceso en lugar de denegarlo.

Las reglas provienen del tema

POM LMS no define reglas de permisos. Se configuran en el tema, y el asistente las evalúa a través de la compatibilidad con reglas de permisos del tema.

Si esa compatibilidad no está disponible, el asistente devuelve false: falla denegando, que es la dirección correcta para una comprobación de acceso.

Qué puede exigir una regla

Una regla tiene un tipo de requisito:

Tipo Exige
El rol es / El rol no es Uno de un conjunto de roles, o ninguno de ellos
Ha comprado TODOS / CUALQUIERA / NINGUNO de Una relación de compra con un conjunto de productos
No ha comprado uno de La ausencia de una compra
Suscripción basada en TODOS / CUALQUIERA de Una suscripción a un conjunto de productos

Las reglas de compra pueden exigir además una fecha de compra —una fecha concreta, o más o menos que un periodo atrás—. Las reglas de suscripción pueden exigir además un estado y una fecha de inicio.

No hay ninguna regla que combine una prueba de rol con una prueba de compra. Cuando estés diseñando una funcionalidad en torno a reglas, planifica un requisito por regla.

Los tipos de regla de producto y de suscripción requieren WooCommerce, y los tipos de suscripción requieren además su extensión de suscripciones. Sin ellos, esos tipos no se ofrecen.

Las reglas se vuelven a evaluar en cada llamada

Nada se guarda en caché entre peticiones. Una regla que depende de un estado de suscripción o de una fecha de compra refleja el estado en el momento en que la invocas —que es lo que hace que el acceso de membresía termine correctamente, y lo que hace que las reglas basadas en tiempo cambien su comportamiento sin que nadie toque el sitio—.

Si la invocas muchas veces en una misma petición, guarda el resultado en una variable.

Leer el conjunto de reglas de un curso o lección

$rule_id = pom_lms_get_post_permission_rule( $post_id );

Devuelve el identificador de regla configurado en un curso o lección, o una cadena vacía si no hay ninguno establecido.

Útil para construir vistas de administración —mostrar qué regla gobierna qué curso—. No lo uses para reimplementar el acceso: lee la regla y deja que los asistentes de acceso decidan.

Probar funcionalidades basadas en reglas

Cualquier funcionalidad controlada por una regla necesita al menos dos cuentas: una que coincida y otra que no. Para reglas basadas en tiempo, haz la prueba en ambos lados del límite.

No hay modo de vista previa ni «ver como» —un administrador ve lo que los roles y pedidos de un administrador le permiten, que rara vez es lo que ve un estudiante—.