Update: Copyright years now reflect the year that the file was first
committed.
Refs: PLAT-3200
Test Plan: jenkins is still happy and specs pass!!
Change-Id: Ic26463defe41fc52cf4da8020976394c641f51d5
Reviewed-on: https://gerrit.instructure.com/143545
Tested-by: Jenkins
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Stewie aka Nicholas Stewart <nstewart@instructure.com>
so we don't constantly refetch the same data when running
progressions
test plan:
* module progressions with assignment overrides
should work as before
closes #CNVS-38735
Change-Id: If85cb5f6d736eaebdcd84a5e16fcf1b243ec42aa
Reviewed-on: https://gerrit.instructure.com/123268
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Heath Hales <hhales@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
This cop encourages explit require_dependency calls for ambiguous nested
constants in specs. What does that mean? Consider:
module Analytics
describe Assignments do
Depending on what has been required and/or autoloaded, `Assignments` could
either resolve to `Analytics::Assignments`, or just the top-level
`Assignments`. This is a cause of flickering failures and test-queue woes.
This example should either have an explicit `require_dependency` call, or
get rid of the module and just do `describe Analytics::Assignments``
Correct all existing ones in the codebase, except for a few
ActiveRecord-related ones (the auto-correct isn't quite perfect, i.e. it
assumes the file path will be `const_name.underscore`, which is no bueno
for things like ActiveRecord::ConnectionAdapters::PostgreSQLAdapter)
Test plan:
n/a, specs
Change-Id: Ic24bf3e0f547ca11c46887d4af92804da091912a
Reviewed-on: https://gerrit.instructure.com/98752
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
test plan:
* see the new api endpoints in the calendar events controller
* can use the 'set_course_timetable' endpoint to send a schedule
for a course (optionally per section) with a list of
weekdays (e.g. "Mon,Wed,Fri") and times
* it will automatically generate calendar events from the start date
of the course (or section) to the end date that correspond to the dates
* if the schedule is changed, the old events will be deleted and
new ones generated
* can also use the 'set_course_timetable_events' endpoint to
generate events from a complete list
closes #CNVS-30523
Change-Id: Idf2b4047af14a6e71838bbe9672583f5bddc3e9f
Reviewed-on: https://gerrit.instructure.com/86051
Tested-by: Jenkins
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Heath Hales <hhales@instructure.com>
Product-Review: Hilary Scharton <hilary@instructure.com>
fixes CNVS-16376
test plan:
- enable account alerts in account settings
- enroll a teacher in a course as section limited (they should be the only
teacher)
- make sure the teacher has a verified email address
- visit the teacher's notification preferences page to make sure there is
a notification policy set up for the alert notification. confusingly, this
is not the same as the "Alert" section on the page, this notification policy
actually cannot be customized, but visiting the page will create it if it
doesn't already exist.
- the annoying thing about this alert notification policy is setup is that it
is set up to be a 'daily' policy, and it can't be customized. this means
that even after the job runs and creates the message successfully, it won't
actually be sent until the following daily batch. to fix this for testing,
you can make the notification policy immediate by running the following in
a rails console:
```
NotificationPolicy.
where(:notification_id => Notification.by_name("Alert")).
update_all(:frequency => "immediately")
```
- now set up an alert and trigger the conditions for the alert
- alert messages are only computed once per day at 11:30 utc. since this is
an inconvenient time to have a patchset checked out, the easiest way to make
this happen manually is to run the following in a rails conosle:
`Alerts::DelayedAlertSender.process`
however, be aware that this job sets a redis key after it runs to make sure
notifications don't get sent twice to the same person, so if you do need to run
it twice in one day for some reason, clear redis between runs.
- the alert message should be sent. if you set up a real email address you
should receive the message, or you can check that it was sent by using the
"View Notifications" tab in the admin tools section of the account.
Change-Id: I3e7dc66975eb666bb498a995a5058d37b991fa91
Reviewed-on: https://gerrit.instructure.com/43138
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Mike Nomitch <mnomitch@instructure.com>
QA-Review: Sean Lewis <slewis@instructure.com>
Product-Review: Matt Fairbourn <mfairbourn@instructure.com>
fixes CNVS-12370
test plan:
course alerts should still work
Change-Id: I877f27506e1c8f5c89de77c266018824b7f5045e
Reviewed-on: https://gerrit.instructure.com/33252
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
Stewie (Nicholas Stewart)