coderabbitai[bot]
commented
4 months ago [!WARNING]
Rate Limit Exceeded
@20wildmanj has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 16 minutes and 20 seconds before requesting another review.
How to resolve this issue?
After the wait time has elapsed, a review can be triggered using the `@coderabbitai review` command as a PR comment. Alternatively, push new commits to this PR. We recommend that you space out your commits to avoid hitting the rate limit.How do rate limits work?
CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our [FAQ](https://coderabbit.ai/docs/faq) for further information.Commits
Files that changed from the base of the PR and between 50318c907a4b66462b499ffb5c739d7bc4550ed3 and 154227bbb7e4091b4bbe79eeb68a8bc4c8a557db.
Walkthrough
This set of changes focuses on refining the functionality related to submissions in a Ruby on Rails application. Key improvements include enhanced error handling and user feedback across controller actions, a significant modification in version numbering logic for submissions, and streamlined redirection and user interaction in views. The adjustments aim to make the application more robust, user-friendly, and maintainable by removing outdated code and implementing more intuitive behavior, particularly around submission versioning and error messaging.
Changes
| File Path | Change Summary |
|---|---|
app/controllers/submissions_controller.rb |
Enhanced error handling and messaging; Removed unused code; Updated redirection logic. |
app/models/submission.rb & app/models/assessment_user_datum.rb |
Added after_destroy callback for version number reset; Adjusted submission lookup logic. |
config/routes.rb |
Excluded :show action from submissions resources. |
spec/controllers/submissions_controller_spec.rb |
Added shared examples for testing various scenarios and user roles. |
app/views/submissions/destroyConfirm.html.erb & app/views/submissions/edit.html.erb |
Updated UI elements and interaction logic for submission deletion and editing. |
Assessment against linked issues
| Objective | Addressed | Explanation |
|---|---|---|
| Version numbering should reset on submission deletion (#2109) | ✅ | The addition of the after_destroy :delete_version_number callback in the Submission model and the corresponding logic in assessment_user_datum.rb directly address the issue's requirement for resetting version numbering upon submission deletion. |
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
damianhxy
Description
#showroute, which is unused, fromroutes.rbandsubmissions_controller.rb#newto have better and correct error-checking so that a 500 error wouldn't occur when a CUD ID didn't exist in the list of CUD IDs provided to the action#createon invalid submission creation#updateBefore: Instructor could still click button to destroy the submission without checking the box but would get an "error" back.
After: Instructor can't click button without having checked the box first.
(also try to fix flaky assessment_spec test by giving capybara expect more wait time)
delete_version_numberto decrease version number when submission is destroyed, and updateupdate_latest_submissionso that it finds the latest submission based on creation date (and checks with version number)Motivation and Context
Fixes #2109
How Has This Been Tested?
http://localhost:3000/courses/AutoPopulated/assessments/lab5/submissions/new?course_user_datum_id=29,30, see that it renders correctlyTypes of changes
Checklist:
overcommit --install && overcommit --signto use pre-commit hook for linting