Precedencia de acceso
El orden en el que se aplican las comprobaciones y lo que ese orden significa en la práctica.
La secuencia
Para un curso
1. Login required? → signed out → BLOCKED
2. Course permission rule → the rule decides → STOP
3. Paid course? → purchase decides → STOP
4. Otherwise → OPENPara una lección
0. Attached course? → none → does not resolve
1. Login required? → signed out → BLOCKED
2. Lesson permission rule → the rule decides → STOP
3. Course permission rule → the rule decides → STOP
4. Otherwise → the course's access decidesAdemás: una lección de vista previa se puede leer de todos modos, salvo que el curso exija iniciar sesión para las vistas previas.
Las reglas detienen la cadena
En cuanto se aplica una regla de permiso, la evaluación se detiene ahí. Todo lo que venga después no se consulta.
Dos consecuencias que sorprenden a la gente:
Una regla en el curso hace que el interruptor de pago no haga nada. Si configuras ambas cosas, la regla decide. Para usar la comprobación de compra, no configures una regla.
Una regla en una lección hace que la regla del curso no haga nada para esa lección. Así, una regla de lección puede ser menos restrictiva que la del curso y abrirá la lección a estudiantes que no pueden abrir el curso.
El requisito de inicio de sesión es diferente
Se comprueba primero y solo elimina acceso. Nada más adelante en la cadena puede dejar pasar a un visitante que no haya iniciado sesión, excepto una lección de vista previa, que es una vía independiente.
Eso lo convierte en el único ajuste que puedes añadir a cualquier curso sin tener que volver a probar todo lo demás, siempre que también ofrezcas a los visitantes que no han iniciado sesión una forma de entrar.
Las vistas previas quedan fuera de la cadena
Una lección de vista previa no se evalúa en absoluto frente a las reglas del curso. Lo único que la condiciona es el ajuste del curso Las lecciones de vista previa también requieren iniciar sesión.
Por eso las vistas previas deben auditarse visualmente: nada en la configuración de acceso del curso te dice qué lecciones están abiertas.
Combinaciones prácticas
| Ajuste del curso | Ajuste de la lección | Resultado |
|---|---|---|
| Regla A | — | La regla A decide |
| Regla A | Regla B | La regla B decide para esa lección |
| Regla A | Vista previa | Cualquiera puede leer esa lección |
| De pago | — | La compra decide |
| De pago | Regla B | La regla B decide para esa lección; no se comprueba la compra |
| De pago + Regla A | — | La regla A decide; se ignora el ajuste de pago |
| Inicio de sesión + Regla A | — | Con sesión iniciada y cumpliendo la regla A |
| Inicio de sesión + Vista previa | Vista previa | La vista previa es legible, salvo que la vista previa con inicio de sesión esté activada |
Las dos filas en negrita son las que provocan cursos mal configurados.
Diseñar teniéndolo en cuenta
- Un modelo por curso. Decide entre inicio de sesión, regla o pago, y usa ese.
- Las anulaciones son excepciones. Si varias lecciones anulan el modelo, el modelo del curso es incorrecto.
- Nunca confíes en que dos mecanismos se combinen. No se suman; el primero que se aplica gana.
- Recuerda que una regla tiene un único tipo de requisito. Puede enumerar varios roles o varios productos, y una regla de compra o suscripción puede añadir una condición de fecha, pero una prueba de rol y una prueba de compra no pueden compartir la misma regla. Un curso, un requisito.
Verifica la precedencia en tu propio curso
- Configura una regla de curso y un interruptor de pago a la vez.
- Inicia sesión como un estudiante que cumpla la regla pero que no haya comprado.
- Confirma que entra, lo que demuestra que la regla ha sustituido a la comprobación de compra.
- Elimina la regla y confirma que ese mismo estudiante queda ahora bloqueado.
- Decide qué comportamiento quieres realmente y configura solo ese.