Nested Placement Validations

[adamjcolvin]

Context

Trello

When we create placements as part of creating a trainee, we don't quite follow the same logic as when creating a placement on its own. When creating a placement on its own, we don't seem to use the hesa mapping logic that we use when creating them with a trainee. I'm not sure if this is what we expect, but on looking at the hesa mapping logic, it seemed that was an issue with it.

def urn
  urn = @params[:urn]
  return if school_urn_applicable?(urn)

  urn
end

def school_urn_applicable?(urn)
  Attributes::NOT_APPLICABLE_SCHOOL_URNS.exclude?(urn)
end

This logic seems to return nil for the URN if the URN is not within the array NOT_APPLICABLE_SCHOOL_URNS. This will be most URNs since the array is only small:

NOT_APPLICABLE_SCHOOL_URNS = %w[900000 900010 900020 900030].freeze

Changes proposed in this pull request

I've added a test to the post_hesa_trainees_spec which reproduces the issue. I've then updated the logic in the hesa_mapper so that the test now passes.

Guidance to review

Should we actually be using the hesa mappers when creating a single placement, as we do for nested placements?

Important business

• Does this PR introduce any PII fields that need to be overwritten or deleted in db/scripts/sanitise.sql?
• Does this PR change the database schema? If so, have you updated the config/analytics.yml file and considered whether you need to send 'import_entity' events?
• Do we need to send any updates to DQT as part of the work in this PR?
• Does this PR need an ADR?

NB: Please notify the #twd_data_insights team and ask for a review if new fields are being added to analytics.yml

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud