Give Moodle learners access until a date — without cohort sync

You need to give a learner — or 480 of them — access to a course until a specific calendar date, after which the door closes on its own. If those learners came in through cohort sync, Moodle™ gives you no field for that. There is no end date to set on a cohort enrolment. There never will be.

People google this as "moodle enrolment expire on specific date", "give access until a date moodle", and the more resigned "cohort sync no end date". The usual forum answer is a scheduled task or a spreadsheet reminder to suspend people by hand. Neither is necessary.

Our version of the problem: roughly 480 learners across 4 courses had just been expired by an annual cohort-expiry job — correctly — but a contract said they were owed access until a fixed end date a few months out. So we needed access restored, bounded by that exact date, and invisible to the very expiry machinery that had just removed them.

Re-adding them to the cohort would have restarted the annual clock. That was off the table.

The fix is one function call, and Moodle enforces the deadline itself. This post is the whole thing: why cohort sync can't do it, which enrolment method can, the copyable script, and how to prove the shutoff actually happens before you trust it at scale.

The right channel

Which Moodle enrolment method supports a per-user end date?

Manual enrolment. The enrol_manual plugin writes a per-user timeend into mdl_user_enrolments, and it is a completely separate plugin from enrol_cohort — separate instance in mdl_enrol, separate rows, separate lifecycle. Any cohort-expiry job you run, native sync included, cannot see it and cannot touch it.

The part that surprises people: the expiry needs no cron job of yours. Moodle checks timestart/timeend at read time — require_login() calls down into is_enrolled() with the active-only flag, and the instant now > timeend that check flips to false. Access dies at the deadline whether or not any scheduled task ever runs. Nothing to schedule, nothing to monitor, nothing to revert.

Before changing anything, look at what channels a learner currently has in the course:

SELECT e.enrol, ue.status, ue.timestart, ue.timeend
FROM mdl_user_enrolments ue
JOIN mdl_enrol e ON e.id = ue.enrolid
WHERE ue.userid = :userid AND e.courseid = :courseid;

Cohort rows will show timeend = 0. After the fix you'll see a second row, enrol = 'manual', with your cutoff timestamp in timeend. Both can coexist — more on that in the gotchas.

Verification

How do I verify the access actually shuts off?

Do not take the mechanism on faith — we didn't. Before touching the 480, we ran a lifecycle test on a scratch account with timeend = now + 90 seconds:

// scratch account, deadline 90 seconds out
$plugin->enrol_user($inst, $testuid, 5, time(), time() + 90,
                    ENROL_USER_ACTIVE, true);

var_dump(is_enrolled($ctx, $u, '', true));   // bool(true)  — before the deadline
// ... wait 90 seconds ...
var_dump(is_enrolled($ctx, $u, '', true));   // bool(false) — access denied
var_dump(is_enrolled($ctx, $u, '', false));  // bool(true)  — still visible to reporting

That split is the behaviour you're buying, proven on live data: is_enrolled($ctx, $u, '', true) — the active-only check that gates actual access — flips to FALSE at the deadline, while is_enrolled($ctx, $u, '', false) stays TRUE so completion reports, grade exports, and audit queries still see the learner.

Active before, auto-denied after, still enrolled-for-reporting. Then, and only then, scale.

Choosing the right tool

What if it's a whole cohort that should expire every year?

Then this is the wrong post — deliberately. enrol_manual + timeend is the right shape for a fixed calendar date applied to a known list of people: a contract end, a pilot window, a grace period. It is the wrong shape for "every member of these cohorts gets N days from the day they joined" — you'd be hand-computing hundreds of individual deadlines that a membership-driven job should own.

For that standing policy — the one that expired our 480 in the first place — you want a batched, guardrailed cleanup job keyed on mdl_cohort_members.timeadded. We wrote that one up separately: making Moodle cohort memberships expire after a year. The two approaches compose: the cohort job handles the population-level rule, and manual-with-timeend handles the exceptions the rule can't express.

If you'd rather hand someone the contract and the learner list

Everything above is enough to do this yourself — the test-then-scale sequence included, and we'd suggest not skipping it. But if your enrolment setup has accumulated layers nobody fully trusts anymore, or you want the date-bounded access wired up with logging and a rollback path, this is squarely the kind of scripting our Moodle development work covers. Tell us what the access rules are supposed to be and we'll tell you which enrolment machinery should own each one — we reply within one business day.