Issue 6225: Allow multiple periods in Assignments API routes

[sophia-huynh]

Proposed Changes

Updated the POST /api/courses/:course_id/assignments and PUT /api/courses/:course_id/assignments/:id API routes to accept the parameters submission_rule_type and submission_rule_periods, the latter allowing for one or more submission rule periods.

While there was formerly an implementation that would allow for a single submission rule to be included with a single period, this did not work and was undocumented. When the related parameters were provided, no errors were raised, but no updates were made. The related parameters have been removed and replaced with submission_rule_periods, as they weren't documented or functional in the first place.

Closes #6225

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)	X
🎨 User interface change (change to user interface; provide screenshots)
♻️ 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

Formerly, there were checks for submission_rule.valid? which never succeeded due to the relationships/dependencies between submission rules, periods, and assignments. Thus, the rules were never updated (and the code within the conditional also wouldn't work correctly), and then a success was returned afterwards.

[coveralls]

Coverage Report for CI Build 33665335750

Coverage increased (+0.04%) to 90.731%

Details

• Coverage increased (+0.04%) from the base build.
• Patch coverage: 2 uncovered changes across 1 file (90 of 92 lines covered, 97.83%).
• No coverage regressions found.

Uncovered Changes

File	Changed	Covered	%
app/controllers/api/assignments_controller.rb	19	17	89.47%
Total (2 files)	92	90	97.83%

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	52447
Covered Lines:	48610
Line Coverage:	92.68%
Relevant Branches:	2499
Covered Branches:	1243
Branch Coverage:	49.74%
Branches in Coverage %:	Yes
Coverage Strength:	128.73 hits per line

---

💛 - Coveralls

[david-yz-liu]

So overall we can make use of Rails support for nested attributes to have a more nested structure for these params:

{
  submission_rule_attributes: {
    type: ...,
    period_attributes: [
      { hours: ..., ... },
      ...
    ]
  }
}

This should allow you to create a new SubmissionRule object directly from the submission_rule_attributes, and if the creation fails due to a validation error, an error should be reported automatically, eliminating the need to check for particular keys manually,

[sophia-huynh]

Revised to use nested attributes. However, error checking for missing attributes within periods was still required - or I can't find a way around it.

Without it, the creation doesn't fail properly, and checking .errors.any? seems to always give an error even for correctly created rules (probably for a similar reason as valid?'s failures.) It does raise an error when update is called*, but the error isn't handled elegantly and a traceback gets sent in the response.
* can't modify frozen attributes is the error that gets raised... for some reason I haven't been able to completely figure out. If it was just from the validation failing, then update should have returned false instead.

[david-yz-liu]

Okay, I'm good with the check but the syntax here is kind of hard to read. I would use a more explicit loop instead:

permitted_params[:submission_rule_periods].each do |period|
  if ...
    return
  end
end

[david-yz-liu]

Hm, previously we used [...SubmissionRule].new, which defers the database saving to later. I'd prefer keeping the same behaviour unless there's a particular reason we need to save in this method.

(Saving will run the validations, but I don't think the code using get_submission_rule is checking for validation errors on the submission rule instance returned.)