[jazairi]

Why these changes are being introduced:

An author may legitimately have multiple distinct
theses with holds. We need an affordance for
processors to override the publication block in
such cases.

Relevant ticket(s):

• ETD-704
• ETD-689

How this addresses that need:

• Adds a field to the the processing form that allows processors to override the publication
  block for related theses.
• Manages exceptions to publication blocks in a model that's backed by PaperTrail.
• Refreshes publication readiness when holds are saved, reassigned, or deleted.
• Rechecks holds before queuing publication and when publication jobs run.

Side effects of this change:

Existing stale readiness statuses are not
automatically fixed. However, this is a highly
unlikely edge case.

Developer

Accessibility

• ANDI or WAVE has been run in accordance to our guide.
• This PR contains no changes to the view layer.
• New issues flagged by ANDI or WAVE have been resolved.
• New issues flagged by ANDI or WAVE have been ticketed (link in the Pull Request details above).
• No new accessibility issues have been flagged.

New ENV

• All new ENV is documented in README.
• All new ENV has been added to Heroku Pipeline, Staging and Prod.
• ENV has not changed.

Approval beyond code review

• UXWS/stakeholder approval has been confirmed.
• UXWS/stakeholder review will be completed retroactively.
• UXWS/stakeholder review is not needed.

Additional context needed to review

It's easiest to test using the preseeded data in the staging db. I've loaded a copy of that db into the review app.

Code Reviewer

Code

• I have confirmed that the code works as intended.
• Any CodeClimate issues have been fixed or confirmed as
  added technical debt.

Documentation

• The commit message is clear and follows our guidelines
  (not just this pull request message).
• The documentation has been updated or is unnecessary.
• New dependencies are appropriate or there were no changes.

Testing

• There are appropriate tests covering any new functionality.
• No additional test coverage is required.

[coveralls]

coverage: 98.382% (+0.08%) from 98.298% — etd-704 into main

[Copilot]

🟡 Changes recommended

The change introduces synchronous N+1 queries across publication batches and can reject unchanged unchecked exceptions after hold removal, discarding metadata edits.

2 open issues

• Batch hold eligibility checks to avoid N+1 queries · New
• Treat stale unchecked exceptions as idempotent no-ops · New

What changed in this PR

This PR lets processors waive publication blocks caused by holds on distinct related theses, while preserving direct holds and other readiness requirements.

Changes:

• Adds directional, audited exceptions and controls to grant or revoke them in the processing form.
• Refreshes readiness when holds change and rechecks holds before queuing and executing publication.
• Adds regression tests for authorization, audit history, rollback, and publication safeguards.

File	Description
test/​models/​related_hold_exception_test.rb	Tests exception validation, persistence, rollback, and cleanup.
test/​models/​hold_test.rb	Tests readiness updates after hold changes.
test/​jobs/​dspace_publication_job_test.rb	Tests publication safeguards against current holds.
test/​controllers/​thesis_controller_test.rb	Tests review permissions, processing updates, and publication filtering.
db/​schema.rb	Records the exception table and constraints.
db/​migrate/​20261105120000_create_related_hold_exceptions.rb	Creates directional exceptions with database integrity checks.
app/​views/​thesis/​process_thesis.html.erb	Adds related-thesis details and exception checkboxes.
app/​models/​thesis.rb	Applies exceptions to readiness and saves reviews transactionally.
app/​models/​related_hold_exception.rb	Validates and audits exception grants and revocations.
app/​models/​hold.rb	Refreshes affected theses after hold saves and deletions.
app/​jobs/​dspace_publication_job.rb	Rechecks holds before publication proceeds.
app/​controllers/​thesis_controller.rb	Handles review submissions and queues eligible publication candidates.

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

The attachment-race retry can reuse a stale association from the rolled-back attempt, skip recreating the exception, and lose the processor’s decision; reload the association before building the lookup.

1 open issue

• Batch hold eligibility checks to avoid N+1 queries

1 previously missed issue

In code that hasn't changed since last review

Reload persisted exceptions before retrying attachment association

app/​models/​related_hold_exception.rb:48

On the attachment-race retry, this association can still contain the exception created during the first attempt even though that attempt's transaction rolled back. Reusing the same thesis object then treats the rolled-back exception as existing, so line 52 skips recreating it and the successful retry loses the processor's decision. Reload the association before building this lookup so each attempt uses persisted exceptions.

1 resolved since last review

• Treat stale unchecked exceptions as idempotent no-ops

_{Review effort: Balanced}

[jazairi]

🔵 Needs a closer look

The attachment-race retry can reuse a stale association from the rolled-back attempt, skip recreating the exception, and lose the processor’s decision; reload the association before building the lookup.

1 open issue

• Batch hold eligibility checks to avoid N+1 queries

1 previously missed issue
In code that hasn't changed since last review

Reload persisted exceptions before retrying attachment association
app/​models/​related_hold_exception.rb:48

On the attachment-race retry, this association can still contain the exception created during the first attempt even though that attempt's transaction rolled back. Reusing the same thesis object then treats the rolled-back exception as existing, so line 52 skips recreating it and the successful retry loses the processor's decision. Reload the association before building this lookup so each attempt uses persisted exceptions.

1 resolved since last review

• Treat stale unchecked exceptions as idempotent no-ops

Review effort: Balanced

This is incorrect. The stale association exists, but the processor’s decision isn’t lost. Saving the thesis automatically saves the retained exception, including its PaperTrail audit.