Access precedence

The order in which checks are applied, and what that order means in practice.

The sequence

For a course

1. Login required?        → signed out → BLOCKED
2. Course permission rule → the rule decides → STOP
3. Paid course?           → purchase decides → STOP
4. Otherwise              → OPEN

For a lesson

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 decides

Plus: a preview lesson is readable regardless, unless the course requires login for previews.

Rules stop the chain

Once a permission rule applies, the evaluation stops there. Whatever comes after it is not consulted.

Two consequences that surprise people:

A rule on the course means the paid toggle does nothing. If you set both, the rule decides. To use the purchase check, do not set a rule.

A rule on a lesson means the course's rule does nothing for that lesson. So a lesson rule can be less restrictive than the course's, and it will open the lesson to students who cannot open the course.

The login requirement is different

It is checked first and it only ever removes access. Nothing later in the chain can let a signed-out visitor through — except a preview lesson, which is a separate path.

That makes it the one setting you can add to any course without re-testing everything else, as long as you also give signed-out visitors a way to sign in.

Previews sit outside the chain

A preview lesson is not evaluated against the course's rules at all. The only thing that constrains it is the course's Preview lessons also require login.

That is why previews must be audited visually: nothing in the course's access configuration tells you which lessons are open.

Practical combinations

The two bold rows are the ones that cause misconfigured courses.

Designing around it

• One model per course. Decide login, rule or paid, and use that.
• Overrides are exceptions. If several lessons override, the course's model is wrong.
• Never rely on two mechanisms to combine. They do not add up; the first one that applies wins.
• Remember that a rule has a single requirement type. It can list several roles or several products, and a purchase or subscription rule can add a date condition — but a role test and a purchase test cannot share one rule. One course, one requirement.

Verify precedence on your own course

1. Set a course rule and a paid toggle together.
2. Sign in as a student who satisfies the rule but has not bought.
3. Confirm they get in — proving the rule replaced the purchase check.
4. Remove the rule and confirm the same student is now blocked.
5. Decide which behavior you actually want, and configure only that.