feat: assign a grade of 0 to collected submissions that are empty

[YheChen]

Proposed Changes

When submissions are collected in bulk, groups that submitted nothing still produce a submission — it is just empty. Its result is created with a marking state of "In Progress" and no marks, so an instructor has to open each one and enter a 0 by hand before results can be released. In a large course that is a lot of clicking, and it is easy to miss a group.

This adds a "Assign grade of 0 to collected submissions that are empty." checkbox to the bulk submission collection modal, checked by default. When it is selected, every newly collected submission is checked for files; any submission with none gets a mark of 0 on every criterion and has its result's marking state set to "Completed".

Implementation:

• collect_submissions_modal.jsx — the new checkbox, in the Collection options fieldset. It is shown for scanned exams as well, where an empty submission means no pages were assigned to that group.
• submission_table.jsx / SubmissionsController#collect_submissions — pass the choice through as assign_zero_to_empty.
• SubmissionsJob — after the submission rule is applied, an empty submission (Submission#is_empty, which the collector already sets from whether any submission files were populated) has its marks zeroed and its result completed. A failure there is reported through the job's existing warning-message channel rather than aborting the rest of the batch.

Behaviour worth flagging for review: if both this option and Retain existing grading data are selected and a recollected submission turns out to be empty, the retained marks are overwritten with 0. This is deliberate and covered by a spec, but see the question below.

Scope: only the bulk collection modal. The API collection route and manual single-revision collection are unchanged — the option defaults to off there, so their behaviour is identical to before.

Screenshots of your changes (if applicable)

Type of Change

(Write an X or a brief description next to the type or types that best describe your changes.)

Type	Applies?
🚨 Breaking change (fix or feature that would cause existing functionality to change)
✨ New feature (non-breaking change that adds functionality)	X
🐛 Bug fix (non-breaking change that fixes an issue)
🎨 User interface change (change to user interface; provide screenshots)	X
♻️ Refactoring (internal change to codebase, without changing functionality)
🚦 Test update (change that only adds or modifies tests)
📦 Dependency update (change that updates a dependency)
📖 Documentation update (change that updates documentation)
🔧 Internal (change that only affects developers or continuous integration)

Checklist

(Complete each of the following items for your pull request. Indicate that you have completed an item by changing the [ ] into a [x] in the raw text, or by clicking on the checkbox in the rendered description on GitHub.)

Before opening your pull request:

• I have performed a self-review of my changes.
  • Check that all changed files included in this pull request are intentional changes.
  • Check that all changes are relevant to the purpose of this pull request, as described above.
• I have added tests for my changes, if applicable.
  • This is required for all bug fixes and new features.
• I have updated the project documentation, if applicable.
  • This is required for new features.
• If this is my first contribution, I have added myself to the list of contributors.

After opening your pull request:

• I have updated the project Changelog (this is required for all changes).
• I have verified that the pre-commit.ci checks have passed.
• I have verified that the CI tests have passed.
• I have reviewed the test coverage changes reported by Coveralls.
• I have requested a review from a project maintainer.

Questions and Comments

(Include any questions or comments you have regarding your changes.)

[coveralls]

Coverage Report for CI Build 35003021117

Warning

No base build found for commit daa4416 on master.
Coverage changes can't be calculated without a base build.
If a base build is processing, this comment will update automatically when it completes.

Coverage: 90.767%

Details

• Patch coverage: 1 uncovered change across 1 file (71 of 72 lines covered, 98.61%).

Uncovered Changes

File	Changed	Covered	%
app/jobs/submissions_job.rb	6	5	83.33%
Total (6 files)	72	71	98.61%

Coverage Regressions

Requires a base build to compare against. How to fix this →

---

Coverage Stats

Relevant Lines:	52836
Covered Lines:	48990
Line Coverage:	92.72%
Relevant Branches:	2517
Covered Branches:	1252
Branch Coverage:	49.74%
Branches in Coverage %:	Yes
Coverage Strength:	128.19 hits per line

---

💛 - Coveralls