Set up notifications

LOOP sends five notices, and only five. They exist from the moment the plugin is installed: there is nothing to create and nothing to delete.

Notice	Sent when
Enrolment notice	Somebody is enrolled on a course belonging to a certification
Completion notice	Somebody completes an edition and earns a certificate
Expiry warning	A certificate is approaching its expiry date
Overdue reminder	A completion deadline has passed with no completion
Expiry notice	A certificate has passed its expiry date

Setting up notifications means answering two separate questions, in two places:

• What does it say, and who receives it? Set once for the whole site, under LOOP → All messages.
• Which certifications send it, and how many days of notice do they give? Set on each certification, in the Notifications section of its form.

Edit the wording

Open LOOP → All messages. Five rows, one per notice.

Use Actions → Edit on the notice you want to change.

Field	What it does
Enabled	Unchecking it stops this notice being queued from the next matching event onward, for every certification. Anything already queued is still sent.
Timing	For the enrolment and completion notices, Offset (days) — 0 sends immediately. For the other three it reads Set on each certification, because their days come from the certification.
Recipient	User sends to the person concerned. Manager sends to the addresses set on the certification instead.
Attach calendar event (ICS)	Attaches a calendar entry, so the date lands in the recipient's calendar. Available on the enrolment notice and the expiry warning.
Certifications	Which certifications currently send this notice. Change it on the certification, not here.
Subject, Message body	The wording, per language.

The enrolment and completion notices follow something the person has just done, so their form carries an offset instead:

Use placeholders

Both the subject and the body accept placeholders, replaced per recipient when the notice is queued:

Hi {firstname}, your {certificationname} certificate expires on {expirydate}.
Enrol in {coursename} here: {courseurl}

The full list is in Notices and placeholders. Anything with no value at send time is replaced with nothing.

Set the days of notice on each certification

Open the certification, and use the Notifications section of its form.

• Notices this certification sends — five checkboxes. All five are on when a certification is created. Switching one off silences it for this certification only.
• Expiry warnings (days before) — for example 60, 30, 7 sends three warnings about the same expiry. Empty sends none.
• Overdue reminders (days after) — counted from the completion deadline. 0, 15, 30 sends one on the deadline itself and two more later.
• Expired reminders (days after) — counted from the expiry date.

Two different numbers decide "when"

The certification's expiration warning (days) decides when somebody's status turns to Expiring on the dashboards. The Expiry warnings (days before) list decides when the email is queued. Neither reads the other.

If the first warning day is not the same as the status threshold, the email arrives on a different day from the one the dashboard changed colour. The form tells you when the two differ and leaves the choice to you — either can be the one you meant.

Who counts as "the manager"

For a notice whose recipient is Manager, LOOP looks for:

1. the Manager emails set on the certification;
2. failing that, the site-wide Fallback manager emails setting.

These are addresses you type, and not a manager relationship read from Moodle: the notice goes to the same addresses for everybody covered by that certification.

With neither set, the notice has nowhere to go. LOOP flags it three times: a Manager notice badge in the Warnings column of Manage certifications, Won't send in that notice's own column on the same page, and Add manager email as the suggested action on the Home dashboard. The notice itself is discarded rather than retried, with the reason recorded — fix the address and the next run queues it again.

When a notice goes to several manager addresses, each is attempted, and a failure on one does not stop the others.

Translate a notice

Each notice carries a subject and a body per language. The edit form has one tab per installed language pack; English is required.

At send time LOOP picks the translation matching the recipient's Moodle language, then falls back until it finds text: the parent language (en_us falls back to en), then the site's default language, then English.

A yellow Translations badge in the list means no dedicated translation exists for that language. It does not mean the notice fails to send — the fallback chain still delivers it.

Hand the wording to a translator

LOOP → All messages has Export notification texts and Import notification texts. The file has one row per notice and language:

trigger_event,lang,subject,full_message
enrolled,en,Your {certificationname} training,"<p>Hello {firstname}…</p>"
enrolled,de,Ihre {certificationname}-Schulung,"<p>Hallo {firstname}…</p>"

Text only. The recipient, whether a notice is switched on, the calendar attachment and the send delay are not in the file and cannot be changed from it.

Two rules worth knowing:

• A language missing from the file is left alone, so a translator can deliver one language at a time. The configuration import works the same way: what a file does not name, it does not touch.
• To remove a translation, empty both its subject and its body. This is refused for your site's default language and for English, because every fallback chain ends there.

A language your site has no pack for is accepted with a warning rather than refused, so a file from a site with more language packs still imports.

The export works without a licence; the import needs one, exactly as saving the text on the edit form does.

Test a notice before it reaches anybody

Every notice has Send a test to myself, in its row on the list and at the bottom of its edit form.

It asks two things — which certification the notice should be about, and which language to render — and sends one copy to your own address.

• The course named is the one on that certification's first edition. A certification with no editions leaves the course placeholders empty, which is also what happens before anybody is enrolled.
• The dates are what that certification's own validity period, completion timeframe and hard deadline produce from today, so the test checks the configuration as well as the wording.
• The person is you: your name fills {firstname} and {lastname}.

A test of a Manager-recipient notice still comes to you, not to the configured manager addresses. The language is the one you choose, not the one your interface is in.

A test send is a send, so it needs an active licence — see What the licence covers.

It is not recorded as a delivery

A test does not appear in the message delivery log, so it cannot stop a real notice from going out to you. It is recorded in the site log instead — Site administration → Reports → Logs — with the template and the language.

Save the text before testing: the test renders what is stored, not what is in an unsaved form.

What a test cannot tell you

Whether the notice goes out on the right day. To check the timing, set up a throwaway certification whose numbers put a fresh completion straight into the window, complete the course as a test account, then run the relevant task by hand instead of waiting for the night — see Command line. The reminder lands in the Mail queue, where its row offers an immediate send.

An expiry warning that missed its own date is dropped

If an expiry warning is still in the queue when the expiry it announces arrives — the licence lapsed, cron stopped for a week, the queue stayed full — it is discarded instead of delivered, with the reason written to the cron output. The message would tell somebody to prepare for something that has already happened.

The other four notices are never dropped. To write to people whose certificate has already run out, use the expiry notice.