Change-Id: Ic1f07de07910a4fac5c091df3b9f24793f0f9526
Reviewed-on: https://gerrit.instructure.com/120440
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
Product-Review: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
refs #CNVS-26056
Change-Id: Ia94ee2fcfded1ec66cb77a19085b005c81304800
Reviewed-on: https://gerrit.instructure.com/70251
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
extracted out of canvas-lms
refs CNVS-4713
test plan:
* actions that use a slave should still work (dashboard render)
* you should be able to switch envs and users in console
Change-Id: I07dda8057cf94383bc4579f1ef6b5a4b3ffc20b5
Reviewed-on: https://gerrit.instructure.com/19287
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
There are three parts to this:
- API access for site admins and account admins. Account
admins can only see messages for their account.
- Includes start and end time parameters for basic searching
- Summary notification are gathered up per account now, so
account admins will not see a summary notification from
multiple accounts.
fixes CNVS-3695
test plan:
- Verify Admin Access:
- Have a user enrolled in two courses in separate root
accounts.
- Send the user ASAP notification from each account.
- Go to /users/:id/messages (the old interface) and verify
the messages appear there.
- As a site admin, get /api/v1/comm_messages for the user
(see documentation for the api).
- Verify that data for both messages are returned.
- Use the console to give an account admin on one of the
accounts :read_messages permissions.
- As the account admin, get /api/v1/comm_messages for the
user.
- Verify that only the message for the admin's account is
returned.
- Verify start_time and end_time parameters
- Use the console to modify the created_at field for the
user's messages
- As a site admin, get /api/v1/comm_messages for the user,
specifying various combinations of start_time and
end_time, and make sure the appropriate messages are
returned.
- Verify account based summaries
- Set the notification policies for the user to a summary
setting (daily or weekly)
- Send multiple notifications to the user from each account.
- Use the console to run the
SummaryMessageConsolidator::process function.
- View /messages for the user and verify that separate
summaries are sent for each account.
Change-Id: Ie33ec02cc2033a1cc2f1fcbe538b76792aab0e6c
Reviewed-on: https://gerrit.instructure.com/18586
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Mark Ericksen <marke@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
Product-Review: Marc LeGendre <marc@instructure.com>
test plan: set some notification preferences to daily/weekly for a few
different users. after the SummaryMessageConsolidator job runs, the
messages should still get sent, and DelayedMessage.summarize jobs should
be created in batches rather than individually.
Change-Id: I81c0404ad641ef0e89e585b104c7727b16cd800a
Reviewed-on: https://gerrit.instructure.com/13775
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
update_all's update hash doesn't have any magic performed on bare Time
objects; it assumes any Time object it's given is already in UTC. using
a TimeWithZone object (regardless of timezone), which Fixnum#ago and
friends happen to return, is still fine.
Change-Id: I297b2a3211b896b5225ebcfaaee3c1eb56e55fb6
Reviewed-on: https://gerrit.instructure.com/5351
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Simon Williams