FIX BUG: By added continue in approval check

[hemannt003]

Adding continue after the warning, then implementing tests: locating a class/section for the timeslot and ensuring student profiles exist.

Description

The bug

In save_priorities (two-phase lottery: student picks classes per priority slot per timeslot), there’s a check: if the section or parent class isn’t approved (status > 0), the code logs a warning and should not register the student for that class.

The problem was that after logger.warning(...) there was no continue. So the loop kept going: it ran the grade-range check and then created or updated a StudentRegistration anyway. So “unapproved” classes could still get a priority registration.

The fix

Right after the warning, a continue was added so that iteration of the loop stops there for that priority/class. The next items in the same POST (other priority slots) still run normally.

So: warn → skip this class → go to the next rel_index, cls_id in the loop.

The tests (in studentregtwophase tests)

1. Approved path – With a normal scheduled class (section + class both “approved”), posting save_priorities should create a valid Priority/1 registration.

2. Unapproved path – Force ClassSubject and ClassSection to an unapproved status (UNREVIEWED), post the same kind of request, then assert:

   • A WARNING log line appears (the “was not approved” message).
   • No valid Priority/1 registration is created for that class.

Helpers were added to give the student a profile (so grade checks behave) and to find a class/section that actually uses the chosen timeslot after schedule_randomly().

Closes #5331

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Refactor / cleanup
• CI/CD or build change

Testing

• Existing tests pass
• New tests added
• Manually verified

AI Disclosure

Used AI to get better understanding of bug and got approaches to fix it.

Checklist

• Self-reviewed the code
• Updated documentation (if needed)
• No new warnings or errors introduced