Permission-based access
A permission rule is the flexible way to decide who gets into a course: by role, by purchase, by subscription, or by when something happened.
Where rules live
Rules are defined once in the theme's permission-rule options, and then selected on a course or a lesson.
POM LMS does not define rules. If the selector on a course is empty, no rules exist yet — create them in the theme options first.
What a rule can require
| Requirement | Examples |
|---|---|
| Role | Is a member · Is not a subscriber |
| Purchase — all | Has bought every product in a set |
| Purchase — any | Has bought at least one of a set |
| Purchase — none | Has bought none of a set |
| Purchase timing | Bought on a date · more than N days/weeks/months/years ago · less than that |
| Subscription | An active subscription based on any or all of a set of products |
| Subscription state | A given status, with a start date before or after a point |
A rule has one requirement type. You choose Role is, or Has purchased ANY of…, or Subscription based on ALL of… — not two of them at once.
What a single rule can add is detail within that type:
- Selecting several roles matches any of them.
- Selecting several products is combined by the type you chose: all of them, any of them, or none of them.
- A purchase rule can additionally require the purchase to have been made on a date, or more or less than a number of days, weeks, months or years ago.
- A subscription rule can additionally require a status, and a start date before or after a point.
There is no rule that means "a member or someone who bought this" — a role test and a purchase test cannot live in the same rule.
Naming rules
A rule is shared across every course and lesson that selects it, so its name should describe what it requires, not where it is used:
| Good | Poor |
|---|---|
| Active subscription — any plan | Rule for the baking course |
| Members only | Course 3 |
| Bought starter pack over 2 months ago | Advanced access |
A well-named rule is reusable; a course-named rule gets duplicated.
One rule, many courses
That is the strength: change the rule and every course using it follows.
It is also the risk. After editing a rule, test every course that selects it, with a student who should pass and one who should not. There is no warning when a rule change affects a course you were not thinking about.
Rules replace, they do not combine
Once a rule applies, evaluation stops:
- a rule on the course means the paid-course setting is ignored;
- a rule on a lesson means the course's rule is ignored for that lesson.
Since a rule has a single requirement type, that means one course has one requirement. If two different kinds of people should get in — say members and individual buyers — you cannot express it in one rule, and you have to choose which mechanism governs the course.
Time-based rules need boundary testing
Rules that depend on when something was bought, or on a subscription's start date, change behavior over time. A course that works today can block everyone next month.
Test with accounts on both sides of the boundary, and note in your own records when the behavior will change.
Subscription rules need the subscriptions extension
Rules based on subscription status or start date depend on WooCommerce subscriptions being present. Without it, those rule types are not available.
Choosing between a rule and the simple settings
| Situation | Use |
|---|---|
| Any signed-in student | The login requirement |
| One product, one course | The paid-course setting |
| Several products | A rule |
| A subscription | A rule |
| A role | A rule |
| A time window | A rule |
| A requirement you already expressed elsewhere | The existing rule |
When in doubt, use a rule: it expresses more, and it keeps the whole site on one mechanism.
Verify
- Select the rule on the course and update.
- Sign in as a student who should match — the course opens.
- Sign in as one who should not — the no-access message.
- Open a lesson URL directly in both states.
- For a time-based rule, test an account either side of the boundary.
- For a subscription rule, test with an active subscription and with a cancelled one.