closes CNVS-30896
test plan:
when creating and editing assignments, quizzes, and
discussion topics in a course with multiple grading
periods enabled, teachers should not be able to change
the effective due date for anyone who already has
the assignment due in a closed grading period.
Change-Id: I2befe4a7431d4020843013041360b8d7b38c15ec
Reviewed-on: https://gerrit.instructure.com/91671
Tested-by: Jenkins
Reviewed-by: Derek Bender <djbender@instructure.com>
Reviewed-by: Shahbaz Javeed <sjaveed@instructure.com>
QA-Review: KC Naegle <knaegle@instructure.com>
Product-Review: Christi Wruck
destroy! is now a method in rails
refs #CNVS-26056
Change-Id: I66e512265ff5cda6a12d7820e3cf69c77ef9e746
Reviewed-on: https://gerrit.instructure.com/69721
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
Grading Periods previously could overlap in arbitrary ways.
This adds a server side validation to ensure that when a Grading
Period is persisted it will not overlap with existing Grading
Periods in the same Grading Period Group. Grading Periods in
different groups are not validated in this way. The front end will
report errors if attempting to save a grading period that overlaps.
Our definition of overlapping is any two grading periods
intersecting each other except if the end date of an earlier
grading period is equal to the start date of a later grading period
These two grading periods would be considered overlapping
(when in the same group):
GradingPeriod.new(
start_date: 0.months.ago, end_date: 2.months.from_now
)
GradingPeriod.new(
start_date: 1.months.from_now, end_date: 3.months.from_now
)
These two grading periods do *NOT* overlap, even thought the
end_date of the first is the same as the start date of the
second (again, these would need to be in the same group):
GradingPeriod.new(
start_date: 0.months.from_now, end_date: 2.months.from_now
)
GradingPeriod.new(
start_date: 2.months.from_now, end_date: 3.months.from_now
)
Fixes CNVS-19858
Change-Id: I0c901fa35f3225186948bbd8d61ef368cd15c939
Reviewed-on: https://gerrit.instructure.com/53953
Tested-by: Jenkins
Reviewed-by: Dylan Ross <dross@instructure.com>
QA-Review: Michael Hargiss <mhargiss@instructure.com>
Product-Review: Derek Bender <dbender@instructure.com>
fixes CNVS-20361
This is the first step in extracting soft deletion and
only touches grading period models. I audited other models
to see if this extraction would work for them, but no other
models met my criteria which are as follows
- [ ] defines workflow state of _only_ active and deleted
- [ ] active scope where state is active
(not `workflow_state<>'deleted'`)
In `def destroy`:
- [ ] state set to deleted
- [ ] then save
- [ ] runs callbacks
Many variants of soft deletion exist, including scoping
active to `workflow_state<>'deleted'`, not running
callbacks after save, and wrapping the state change in a
transaction block.
This is the first step in making soft deletion behave
consistently. There are approximately 30 models that have
an implementation of soft deletion.
Change-Id: I6cb48571377a4bb403285f95c058020b46ca3a30
Reviewed-on: https://gerrit.instructure.com/53821
Reviewed-by: Derek Bender <dbender@instructure.com>
Product-Review: Strand McCutchen <smccutchen@instructure.com>
QA-Review: Strand McCutchen <smccutchen@instructure.com>
Tested-by: Jenkins
Spencer Olson