Immediate Onboarding API fixes

[jamiebenstead]

Status

• Closes https://github.com/RaspberryPiFoundation/digital-editor-issues/issues/1155
• Closes https://github.com/RaspberryPiFoundation/digital-editor-issues/issues/1173

What's changed?

• Verified school validation is skipped when Immediate Onboarding flag is enabled.

[Copilot]

Pull request overview

This PR removes the “school must be verified” validation from the school student creation flow and teacher invitation flow, aligning behavior with the linked issue.

Changes:

• Removed the verified-school guard from SchoolStudent::Create validation.
• Removed the verified-school model validation from TeacherInvitation.
• Deleted specs that asserted the old “unverified school” failure behavior.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
lib/concepts/school_student/create.rb	Stops rejecting student creation based on school.verified?.
app/models/teacher_invitation.rb	Removes school_is_verified model validation.
spec/concepts/school_student/create_spec.rb	Removes spec coverage for the old unverified-school rejection.
spec/concepts/school_teacher/invite_spec.rb	Removes spec coverage for the old unverified-school rejection.

Comments suppressed due to low confidence (1)

spec/concepts/school_student/create_spec.rb:85

• After removing the "school is not verified" failure case, there’s no spec asserting the new expected behavior (that an unverified school can still create a student successfully). Add a context/example for an unverified school to prevent regressions back to the old restriction.

  context 'when the student cannot be created in profile api because of a 422 response' do
    let(:error) { { 'message' => "something's up with the username" } }
    let(:exception) { ProfileApiClient::Student422Error.new(error) }

    before do
      allow(ProfileApiClient).to receive(:create_school_student).and_raise(exception)
    end

[mwtrew]

Looks fine to me but let's not merge yet.

[zetter-rpf]

Why can't this call SchoolOnboardingService? i.e. remove the branching entirely?

The School onboarding service also does a call to ProfileApiClient.create_school which isn't here. Isn't that important?

[mwtrew]

The School onboarding service also does a call to ProfileApiClient.create_school which isn't here. Isn't that important?

For immediately-onboarded schools, that has already happened when the school is created (which is probably why the previous version of this did nothing when the flag was enabled).

This branch is supposed to deal with schools created prior to Immediate Onboarding. I was under the impression that these schools had already been created both in API's DB and in Profile, and that the last thing the user needs to be able to access their school is role assignment. That role assignment logic is here, because it didn't look like SchoolOnboardingService's logic is idempotent.

I might be mistaken about one or both of these things, in which case using SchoolOnboardingService could work.

[zetter-rpf]

I thought when this is shipped all the existing schools in the queue would be able to use code editor without action from us (although we would want to notify them).

This seems to require us to press the 'verify' button for everyone - is that right? Maybe this has changed since I last heard the plan.

[mwtrew]

I thought when this is shipped all the existing schools in the queue would be able to use code editor without action from us (although we would want to notify them).

This seems to require us to press the 'verify' button for everyone - is that right? Maybe this has changed since I last heard the plan.

That's right. We would at least need to assign them roles (and possibly create the schools in Profile - following your other comment I'm no longer sure about this) before they can access their school, which the verification process does. It also seems like making sure the verification process still works is a priority, so we'd be doing that work anyway. We didn't explore doing this automatically or through a migration, but perhaps we could.

[zetter-rpf]

That's right. We would at least need to assign them roles (and possibly create the schools in Profile - following your other comment I'm no longer sure about this) before they can access their school, which the verification process does. It also seems like making sure the verification process still works is a priority, so we'd be doing that work anyway. We didn't explore doing this automatically or through a migration, but perhaps we could.

I don't mind if we we do it by code or manually, but It would be good to eventually migrate everyone so we can remove the verify code path.