Remove need for session request when creating mentoring sessions

[AxonC]

Summary

Implements TECH-734 (PR1 of TECH-700 / stakeholder AC TECH-732).

Training Panel mentoring no longer depends on pending CTS session requests. Mentors see students who hold an active Training Place and have availability, then create a session (with position selection) instead of accepting a pre-created request.

This is the Training Panel cutover slice only. It does not change daily availability enforcement emails/rules (TECH-735) or remove the hourly auto-create session-request job (TECH-733).

Why this is safe vs current behaviour

What stays the same

• Mentors still book from the Availability Gantt against a student’s availability window (min 45 minutes, overlap callouts, short-notice warning).
• Created sessions are still normal taken CTS sessions rows with Core + CTS bookings and the same accepted-session notifications/emails (copy updated only).
• Reschedule / reallocate / conduct / history flows are unchanged.
• Students without a Training Place are unaffected by this panel path (legacy CTS “Request Session” can still exist outside the panel).
• The hourly job that auto-creates pending CTS requests still runs until TECH-733. The panel simply ignores those pending rows. While that job runs, students keep having requests in CTS, so the existing availability-check rule (availability AND request) continues to pass for Training Place holders.

What changes (and why it is an improvement)

Before	After	Risk mitigation
Gantt only listed students with an untaken CTS session on a mentor callsign	Lists students with an active Training Place intersecting mentor callsigns + availability that day	Eligibility is stricter about training status (LOA / exam-forwarded / future booking excluded)
Mentor “accepted” a fixed pending request position	Mentor selects a CTS position from place ∩ allow-list (default primary)	Position must be on the place and authorized via MentoringPolicy::create
Cancel recreated a pending session request	Cancel does not recreate a request	Student remains bookable again via place + availability; no orphan request spam from panel cancels
Student email: “accepted your mentoring session request”	“booked a mentoring session with you”	Matches the new mental model; no behavioural change to delivery

Intentional non-goals in this PR

• Does not stop auto-creating CTS session requests (TECH-733 — must wait until TECH-734 + TECH-735 are live).
• Does not relax CheckAvailability to availability-only (TECH-735). Shipping this first is safe because auto-create still supplies requests for the old check.
• Public site / policy docs that still mention CTS “Request Session” are unchanged.

Known limitation (documented in code)

MentoringSessionsService::createSession uses DB::transaction() on the default connection only. CTS session/booking writes use the cts connection and are not rolled back if a later Core write fails (same dual-write pattern as existing acceptSession). Notifications use DB::afterCommit() on the Core transaction.

Functional behaviour

Gantt shows a student when all are true:

• Active Training Place whose CTS callsigns intersect the mentor’s allow-list (category filter respected)
• Not on current LOA
• Not exam-forwarded (ATC pending exam)
• No future undoned booked mentoring session on the place’s callsigns
• Has CTS availability on the selected date

Create session:

• Validates availability ownership, place callsigns, mentor authorization, LOA, times
• Creates a taken CTS session + Core/CTS bookings + accepted notifications

Test plan

• As a mentor with callsign permissions, open Training → Mentoring Availability Gantt
• Confirm a Training Place student with availability appears (primary position badge)
• Confirm students without a place, on LOA, exam-forwarded, or with a future booked session do not appear
• Create a session: choose position (default primary), times within availability → session appears in accepted/upcoming
• Cancel that session → confirm no new pending CTS session request is created for the student
• Confirm student notification copy refers to a booked session (not “session request”)
• Confirm hourly auto-create job still runs (no change) and availability checks still pass for students with availability + auto-created request
• Automated: php artisan test tests/Feature/TrainingPanel/Mentor/MentoringPageTest.php tests/Unit/Training/Mentoring/MentoringSessionsServiceTest.php tests/Unit/Notifications/Training/Mentoring/MentoringSessionNotificationsTest.php

Related

• Parent epic: TECH-575
• Follow-ups: TECH-735 (availability checks), TECH-733 (stop auto-create + orphan cleanup)

Made with Cursor

[linear]

TECH-734

[CLC0609]

Alongside this, do we want to remove the ability for students to create session requests on CTS. Once this and the TFP one is in place that won't be needed right?