Skip to content

Conversation

@fspeirs
Copy link
Contributor

@fspeirs fspeirs commented Feb 3, 2026

Fix an incorrect depdendent: rule between SchoolProject and SchoolProjectTransition.

Status

  • Closes RaspberryPiFoundation/digital-editor-issues#1126

Points for consideration:

  • Security
  • Performance

What's changed?

Database and Model Relations and Nullify Rules

Previously, when a SchoolProject was destroyed, there was a rule that dependent school_project_transitions would be nullified rather than destroyed.

At the same time, the definition of a SchoolProjectTransition states that the school_project_id, which refers to the project being transitioned, CANNOT be null.

Therefore, when PR #637 allowed deletion of Students and, consequently, Projects, the error in these relations and nullification rules was exposed.

This leads to an error when deleting a Student who owns projects which have been transitioned.

This PR changes the dependent: rule between SchoolProject and SchoolProjectTransition to destroy the transition when the Proejct is destroyed. It also adds a test to ensure this happens.

Follow on Work

While this PR fixes the immediate problem, there remains an issue that SchoolStudentsController#destroy_batch will return a 200 status code on both success and failure. I suggest we address this in a follow up issue.

Steps to perform after deploying to production

NA

@cla-bot cla-bot bot added the cla-signed label Feb 3, 2026
@fspeirs fspeirs marked this pull request as ready for review February 4, 2026 08:50
Copilot AI review requested due to automatic review settings February 4, 2026 08:50
    Previously, when a SchoolProject was destroyed, there was a rule that
    dependent `school_project_transitions` would be nullified rather than
    destroyed.

    At the same time, the definition of a `SchoolProjectTransition` states
    that the `school_project_id`, which refers to the project being
    transitioned, CANNOT be null.

    Therefore, when PR
    [#637](#637)
    allowed deletion of Students and, consequently, Projects, the error in
    these relations and nullification rules was exposed.

    This leads to an error when deleting a Student who owns projects which
    have been transitioned.

    This commit changes the `dependent:` rule between SchoolProject and
    SchoolProjectTransition to destroy the transition when the Proejct is
    destroyed. It also adds a test to ensure this happens.
@fspeirs fspeirs force-pushed the fs-fix-project-deletions branch from c2e05be to 848f47c Compare February 4, 2026 08:51
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes an incorrect dependent: rule between SchoolProject and SchoolProjectTransition that was causing database constraint violations when deleting students who own projects with state transitions.

Changes:

  • Modified the dependent: rule from :nullify to :destroy to properly cascade deletions
  • Updated the model spec to reflect the corrected dependency behavior
  • Added a comprehensive test to verify transitions are deleted when projects are destroyed

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File Description
app/models/school_project.rb Changed dependent: :nullify to dependent: :destroy for school_project_transitions association
spec/models/school_project_spec.rb Updated spec expectation to match the corrected dependent: :destroy rule
spec/services/student_removal_service_spec.rb Added test case verifying that project transitions are properly deleted when student projects are removed

@fspeirs fspeirs merged commit c689980 into main Feb 4, 2026
6 checks passed
@fspeirs fspeirs deleted the fs-fix-project-deletions branch February 4, 2026 08:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants