Conversation
…il sends if they are supposed to be unenrolled (ie. cancelled/expired, order fail).
|
@cursor review |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 00b8536. Configure here.
| 'anchor' => $last, | ||
| ); | ||
| } | ||
| } |
There was a problem hiding this comment.
Inactivity fires for completed students
High Severity
query_course_inactivity treats any enrolled student with a completion row as stalled once last activity is older than the period. Students who already finished the course stay enrolled, so they match after N days and receive inactivity engagements for a course they completed.
Reviewed by Cursor Bugbot for commit 00b8536. Configure here.
| array_merge( $user_ids, $tree ) | ||
| ), | ||
| OBJECT_K | ||
| ); // db call ok; no-cache ok. |
There was a problem hiding this comment.
Sends re-arm inactivity triggers
High Severity
get_last_activity treats every user-postmeta row on the course tree as student activity. Sending the engagement writes _email_sent (or award meta) on the course, which becomes a newer last-activity date and makes maybe_fire treat the send itself as a re-arm. The same inactivity engagement then fires again every period with no real student activity.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 00b8536. Configure here.
…ing. Add a same-request cache for the course tree scanning.
…ctivity indefinitely based on "activity" of sending them an engagement.
…leted course, warning on saving when it will trigger >=200 emails.
1 participant
Description
Fixes #3064 and #3051
How has this been tested?
Screenshots
Types of changes
Checklist:
Note
High Risk
Large changes to engagement firing, email dupcheck bypass, enrollment validation, and daily batched DB scans that can affect student communications and site load on large catalogs.
Overview
Expands LifterLMS engagements with negative / at-risk triggers (low course grade, repeated quiz failures, cancelled or expired enrollments, failed/refunded/cancelled orders) plus configurable thresholds (course progress %, failure count, inactivity days).
Event-driven path: New hooks map order status changes and course/membership unenrollment into trigger types;
LLMS_Engagements_Thresholdslistens on lesson/course/quiz hooks for progress, grade-below, and multi-fail logic with per-course/quiz fire-once markers. Engagements that fire after access is lost skip the usual enrollment check viaremove_enrollment_check_errors.Daily scan path:
LLMS_Engagements_Scannerruns a recurring Action Scheduler job that batches candidates for login inactivity, stalled course progress, never-started enrollments, completion deadlines, and abandoned quiz attempts. Re-arm markers prevent duplicate fires until activity changes; scan-based emails can bypass the sent-email dupcheck when re-armed.Admin & email: The engagement meta box adds percentage, day-count, and failure-count fields (with filters for add-ons), wires new triggers to course/membership/quiz pickers, and exposes
{related_post_title}in engagement email merge codes.Reviewed by Cursor Bugbot for commit 00b8536. Bugbot is set up for automated code reviews on this repo. Configure here.