Follow-ups for assigned tasks

Claims are for agents: the stale-claim sweep releases any claim after ten minutes, so a person given a task works through assigned_to (usually with a due date) instead, never a claim. Nothing reminded people about the tasks they were given, so since 1.16.0 (#148487) LH_Tasks_follow_up_class (includes/lh-tasks-follow-up-class.php) runs a daily cron on each site over open, live tasks that are hard-assigned, unclaimed and not self-assigned:

• Reminder to the assignee once the task is overdue and has been quiet for a day, or, with no due date, once it has been quiet for 7 days.
• Escalation to the task’s author if it is still quiet 3 days after the reminder. Skipped, with a progress-log note, when the author is the assignee, no longer exists or has no email address (agent accounts).

Quiet means no edit, status change or progress-log entry other than these follow-ups; any activity starts the cycle again. Each step is logged on the task and sent as an email and, when the BuddyPress notifications component is active, as a notification linking to the task’s own page. Completing or cancelling a task removes its follow-up notifications.

While a task is Awaiting review (1.23.0, #150480) the ball is with its author, so the reminder goes to the author instead, with the same day rules and no escalation, since there is nobody above the author to tell. Each hand-over between doer and author (ready to check, sent back) clears the task’s follow-up state and notifications and starts the cycle again. See Review step for delegated tasks.

Cron and filters

• lh_tasks_follow_up: daily cron on each site, first run 1 to 6 hours after it is scheduled.
• lh_tasks_follow_up_task (filter): return false to exclude a task. Args: $include, $task_id.
• lh_tasks_return_follow_up_overdue_quiet_days (default 1), lh_tasks_return_follow_up_quiet_days (default 7), lh_tasks_return_follow_up_escalate_days (default 3) and lh_tasks_return_follow_up_batch_size (default 50) (filters).

Notifications across sites (1.17.2)

BuddyPress notifications are one table shared by every site on the network, but task IDs are per site. Before 1.17.2 the notification text and link were worked out on whichever site displayed it, so a task ID was read as an unrelated local post there (on Princes Park Touch, reminders for lhero.org tasks showed GatherPress event titles, or a bare “Reminder:”). Now:

• Each follow-up notification stores two notification meta values when it is added: lh_tasks_blog_id, the site the task lives on, and lh_tasks_link, the Tasks-tab link worked out there.
• The formatter switches to that site to read the task title, so the same notification reads the same on every site.
• Notifications from before 1.17.2 have no stored site. They are matched to a site that holds a task with that ID, this site first and then the main site, and otherwise shown as a generic “Reminder about a task”. Their link is the displaying site’s Tasks tab.
• Clearing on completion or cancellation only removes notifications whose task lives on the current site, rather than every lh-tasks notification with that item ID network-wide.

Any plugin that raises BuddyPress notifications keyed on a site-local ID needs the same pattern; the network-wide audit is lh-tasks #150537.