Digital-Dabei-Hamburg-Job-Manager/.planning/quick/002-fix-duplicate-mentor-notifications-on-jo/002-PLAN.md

phase, plan, type, wave, depends_on, files_modified, autonomous, must_haves

phase	plan	type	wave	depends_on	files_modified	autonomous	must_haves
quick-002	01	execute	1		includes/class-notifications.php	true	truths artifacts key_links 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 path provides contains includes/class-notifications.php Duplicate notification guard using post meta _ddhh_mentors_notified from to via pattern notify_mentors_on_job_publish post_meta _ddhh_mentors_notified get_post_meta check before scheduling, update_post_meta after scheduling 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.

<execution_context> @/.claude/get-shit-done/workflows/execute-plan.md @/.claude/get-shit-done/templates/summary.md </execution_context>

@includes/class-notifications.php @includes/class-scheduler.php

The bug is in notify_mentors_on_job_publish() (line ~430). The current guard:

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

<success_criteria>

• 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 </success_criteria>

After completion, create `.planning/quick/002-fix-duplicate-mentor-notifications-on-jo/002-SUMMARY.md`