[vikrantwiz02]

Follow-up to #1959. That PR fixed the batch lookup on the upload path; this fixes the same fault on the status-transfer path, which is what actually leaves a student unusable.

Symptom

Student Courses for a roll number answers:

Student a roll number does not have a valid batch assignment. Please contact academic office to complete student setup.

The record is present and reported, but the academic row has no batch:

Student row: batch_id=None  programme='M.Tech'  sem=1
admission:   status=REPORTED  branch='Mechanical Engineering'  spec='Design'  year=2026

Cause

Marking a student REPORTED copies the admission record into the academic tables, and that path carries its own copy of the specialization-to-discipline table:

elif student.specialization == 'Design':
    discipline_name = 'Design'
...
if student.specialization == 'Design':
    batch_obj = Batch.objects.filter(name=programme_name,   # M.Des
                                     discipline=discipline)  # Design

So "specialization Design" is read as M.Des under discipline Design. That holds for M.Des students, but M.Tech Design is run by Mechanical Engineering, so for that student the lookup matched nothing and the academic record was created with no batch — and every page keyed on the batch then fails.

Exactly one student is affected. Of the 22 Design-specialization records for 2026, 21 are M.Des whose discipline really is Design; a roll number is the only M.Tech Design student, alone in his discipline.

Re-uploading the intake file cannot repair it: the upload path refuses an existing student as a duplicate and never revisits the academic row.

Fix

When the specialization-based lookup finds nothing, the batch is taken from the discipline the student's own record states, then from a batch of that name if it is the only one for the year, and the discipline follows whichever batch was found. It only runs after the existing lookup has already failed, so no transfer that works today changes behaviour.

Verified by replaying the reporting cycle for the affected student, rolled back afterwards:

-> NOT_REPORTED  200  removed from main tables         batch=None
-> REPORTED      200  transferred to main academic…    batch=M.Tech Design 2026
final: Student.batch=M.Tech Design 2026  discipline=Mechanical Engineering

Repairing the existing record

Deploying this does not retroactively fix a roll number. Either set his status to NOT_REPORTED and back to REPORTED from the Upcoming Batches student list — which re-runs the transfer, as replayed above — or link the batch directly:

UPDATE academic_information_student s
SET batch_id_id = b.id
FROM programme_curriculum_batch b
WHERE s.id_id = :roll_number
  AND b.name = 'M.Tech Design' AND b.year = 2026 AND b.running_batch = true;

SELECT s.id_id FROM academic_information_student s WHERE s.batch_id_id IS NULL; lists anyone else in the same state.

manage.py check clean, no migrations.