---
phase: quick-002
plan: 01
type: execute
wave: 1
depends_on: []
files_modified:
- includes/class-notifications.php
autonomous: true
must_haves:
truths:
- "Mentors receive notification when a job is first published"
- "Mentors do NOT receive notification when a previously-published job is edited and republished"
- "Each job can only trigger mentor notifications once in its lifetime"
artifacts:
- path: "includes/class-notifications.php"
provides: "Duplicate notification guard using post meta"
contains: "_ddhh_mentors_notified"
key_links:
- from: "notify_mentors_on_job_publish"
to: "post_meta _ddhh_mentors_notified"
via: "get_post_meta check before scheduling, update_post_meta after scheduling"
pattern: "get_post_meta.*_ddhh_mentors_notified"
---
Fix duplicate mentor notifications when a job is edited and republished.
Purpose: Mentors currently receive "new job" notifications every time a job transitions to
publish status -- including after edits (pending -> publish). The notification should only
fire once per job, on the very first publication. Subsequent republications after edits
should be silent for mentors (the admin already gets a separate edit notification).
Output: Updated `notify_mentors_on_job_publish` method with a post meta guard that prevents
duplicate notifications.
@~/.claude/get-shit-done/workflows/execute-plan.md
@~/.claude/get-shit-done/templates/summary.md
@includes/class-notifications.php
@includes/class-scheduler.php
The bug is in `notify_mentors_on_job_publish()` (line ~430). The current guard:
```php
if ( 'publish' !== $new_status || 'publish' === $old_status ) {
return;
}
```
This correctly prevents re-notification when a published post is updated (publish -> publish),
but it does NOT prevent re-notification when a previously-published job is edited and reset
to pending (per decision 03-02: "Post status reset to pending after edit"), then republished
by admin (pending -> publish). This second publish triggers notifications again.
The job lifecycle that causes the bug:
1. Provider submits -> status: pending
2. Admin publishes -> pending to publish -> mentors notified (CORRECT)
3. Provider edits -> status reset to pending (per 03-02)
4. Admin republishes -> pending to publish -> mentors notified AGAIN (BUG)
Task 1: Add post meta guard to prevent duplicate mentor notifications
includes/class-notifications.php
In the `notify_mentors_on_job_publish` method, add a post meta check AFTER the existing
status transition guard (line ~437) and BEFORE the mentor query (line ~442):
1. Check if post meta `_ddhh_mentors_notified` exists and equals `'1'` for this post.
If it does, log a message like "DDHH Job Manager: Skipping mentor notification for
job #%d - mentors already notified on initial publish" and return early.
2. After the `DDHH_JM_Scheduler::schedule_mentor_notification_batch()` call succeeds
(line ~457), set post meta: `update_post_meta( $post->ID, '_ddhh_mentors_notified', '1' )`.
Use underscore-prefixed meta key `_ddhh_mentors_notified` so it is hidden from the
WordPress custom fields UI.
Do NOT change any other logic in this method or file. The existing status transition
guard should remain as-is (it still serves a purpose for publish->publish transitions).
1. Read the modified file and confirm:
- `get_post_meta( $post->ID, '_ddhh_mentors_notified', true )` check exists before mentor query
- `update_post_meta( $post->ID, '_ddhh_mentors_notified', '1' )` exists after scheduling
- No other methods were modified
2. Run `php -l includes/class-notifications.php` to confirm no syntax errors
The `notify_mentors_on_job_publish` method checks for `_ddhh_mentors_notified` post meta
before scheduling notifications, and sets that meta after scheduling. This ensures mentors
are only notified once per job, regardless of how many times the job transitions through
pending -> publish.
1. `php -l includes/class-notifications.php` passes with no syntax errors
2. The `_ddhh_mentors_notified` meta key is checked before notification scheduling
3. The `_ddhh_mentors_notified` meta key is set after successful scheduling
4. No other notification methods were modified
5. The existing `transition_post_status` guard logic is preserved
- First publish of a job (pending -> publish) triggers mentor notifications and sets meta flag
- Subsequent publishes of the same job (pending -> publish after edit) skip mentor notifications
- Admin notifications for edits/republications are unaffected
- No PHP syntax errors introduced