Release Release 2261 · DFE-Digital/schools-experience

Trello card

Context

When a candidate has attended a school experience booking we want to obtain feedback so that we can improve the service.

Changes proposed in this pull request

Add model to capture candidate booking feedback

When a candidate has attended a placement we want to ask them for feedback about their experience.

Add Candidates::BookingFeedback model to capture feedback from users.

Accept feedback for attended bookings

Allow candidates to submit feedback for bookings they have attended.

We use the secure token on the PlacementRequest to allow a candidate to submit feedback.

Candidates can only submit feedback on bookings that they have attended. Feedback can only be submitted once.

Send feedback request emails on confirmation of attendance

When a school indicates that a candidate has attended a school experience booking we want to issue an email that requests feedback.

Add CandidateBookingFeedbackRequest to queue an email to the candidate.

Update School::Attendance to issue feedback requests for attended bookings.

Update ConfirmAttendanceController to load the gitis_contact for bookings prior to processing the attendance; we need the contact information present so that we can access the candidate's email.

Guidance to review

Best reviewed by-commit.

To trigger the feedback request you need to sign up for a placement, accept it as the school and then move its date into the past - you can do this via the Rails console locally in Cloud Foundry:

cf ssh review-school-experience-2261
export PATH=${PATH}:/usr/local/bin
cd /app
./bin/rails c
Bookings::Booking.last.update_attribute(:date, Date.yesterday)

You can then mark it as attended and you should receive the feedback email as the candidate.

Initially I went down the path of implementing the mechanism to send the feedback request in the Booking model in an after_save hook. This proved a bit of a nightmare, whilst it was easy enough to implement it breaks a bunch of tests related to creating attended bookings as the mocked booking never had an associated candidate with contact information present.

To avoid this I opted to move the logic into the Attendance model, which still makes sense but is less robust IMO. I think we could clean up the logic around how contact information is loaded from the API; currently it mostly happens in the controllers and occasionally in services, but it means the state has to be assumed in classes further down the chain (like in models). I would opt to refactor this so the Candidate model is responsible for loading its contact information from the API at the time its accessed, which would massively reduce the complexity around this process and clean up a bunch of repeating logic in various controllers/services.