| @@ -40,12 +40,21 @@ | ||
| 40 | 40 | }); |
| 41 | 41 | |
| 42 | 42 | // Booking completion cron: marks confirmed bookings 'completed' once |
| 43 | 43 | // their tour date has passed, which is what fires the booking.completed |
| 44 | - // email / Email Automation sequence. BookingCronService::register() (its | |
| 45 | - // reminder/expiry events) is not wired anywhere, so nothing here activates | |
| 46 | - // those — only the completion sweep, which self-guards against emailing | |
| 44 | + // email / Email Automation sequence. Self-guards against emailing | |
| 47 | 45 | // historical bookings via an activation floor. |
| 48 | 46 | add_action('init', [BookingCronService::class, 'registerCompletionCron']); |
| 49 | 47 | add_action('yatra_booking_completion', [BookingCronService::class, 'completeFinishedBookings']); |
| 48 | + | |
| 49 | + // Unpaid-booking expiry + pre-trip reminder. These two events were only | |
| 50 | + // ever scheduled (and only ever given a callback) inside | |
| 51 | + // BookingCronService::register(), which is not called anywhere — so the | |
| 52 | + // "Booking Expiry (hours)" setting expired nothing and the reminder | |
| 53 | + // email was only reachable through the admin's manual resend. Wiring | |
| 54 | + // them here is what makes both features actually run; expiry carries its | |
| 55 | + // own activation floor so an existing site cannot mass-cancel a backlog. | |
| 56 | + add_action('init', [BookingCronService::class, 'registerMaintenanceCrons']); | |
| 57 | + add_action('yatra_booking_expiry', [BookingCronService::class, 'expirePendingBookings']); | |
| 58 | + add_action('yatra_booking_reminder', [BookingCronService::class, 'sendBookingReminders']); | |
| 50 | 59 | } |
| 51 | 60 | } |