fixes CNVS-18827
test plan
- cause a summary message to be sent to a bouncing communication
channel
- ensure that the message is not sent
Change-Id: I966a386c6d822db873c4dee19e061b5ca12d060a
Reviewed-on: https://gerrit.instructure.com/49376
Tested-by: Jenkins
Reviewed-by: Matthew Wheeler <mwheeler@instructure.com>
QA-Review: Derek Hansen <dhansen@instructure.com>
Product-Review: Joel Hough <joel@instructure.com>
refs CNVS-16138
test plan:
- create a user, set up a communication channel, and set up a notification to
be 'daily'
- retire the communication channel
- trigger the action that will create the daily notification
- manually trigger the delayed message summarizer job: `DelayedMessage.summarize([DelayedMessage.order(:created_at).last])`
- it should not create a summary message for the retired channel
Change-Id: Id29c6f7d437438894b2e7527ffe7fbe3c220cfda
Reviewed-on: https://gerrit.instructure.com/42380
Reviewed-by: Simon Williams <simon@instructure.com>
Reviewed-by: Matthew Wheeler <mwheeler@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Steven Shepherd <sshepherd@instructure.com>
Product-Review: Matthew Wheeler <mwheeler@instructure.com>
and remove base_ar_class, that does the same thing
Change-Id: Id76a2dcc375cfea397ff4b4853f50d660b6b044c
Reviewed-on: https://gerrit.instructure.com/41783
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Nick Cloward <ncloward@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
fixes #CNVS-14270
move broadcast policy into a gem of its own
to remove plugin deprecation warnings.
TEST PLAN:
-no behavior changes
-regression test notifications
(no need to hit them all, confirm that 3 or
4 separate notifications flow and
that will prove the pipeline)
Change-Id: If8445653ec09ab4d221124d85f9674d1cedd3751
Reviewed-on: https://gerrit.instructure.com/40899
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Matthew Wheeler <mwheeler@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
QA-Review: August Thornton <august@instructure.com>
fixes CNVS-15426
test plan:
- enable account alerts in account settings
- enroll a teacher in a course
- 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 actually 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: Ia3ca030da1896539c6ca193b87c1ce9d3b936ef9
Reviewed-on: https://gerrit.instructure.com/40919
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Liz Abinante <labinante@instructure.com>
QA-Review: Anna Koalenz <akoalenz@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
just use the cached .all, even for associations
test plan:
* go to the notification preferences page as a user
* in console
* np = NotificationPolicy.first; np.notification
* the first time, it should query notification_policy,
and *all* notifications
* do it again, and this time it should not query
notifications, but should still return an object
Change-Id: I3b83ec9ce6f6f6b4d542e83d2b8653b4e221afd4
Reviewed-on: https://gerrit.instructure.com/40460
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
instead of passing an :exportable option to
ActiveRecord::Associations, simply define a constant
on the class containing exportable associations and
attributes. This is due to :exportable breaking
ActiveRecord, and we can't simply monkey-patch in
config/initializers because models are included in
migrations before the initializers are run
Change-Id: I11f1a6b4570c397d8e01010c517bc6efdac7afca
Reviewed-on: https://gerrit.instructure.com/33235
Reviewed-by: Braden Anderson <banderson@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Anthus Williams <awilliams@instructure.com>
QA-Review: Anthus Williams <awilliams@instructure.com>
fixes CNVS-12395
test plan:
please check for regressions around notifications on quiz submissions.
this includes:
- to teachers when the submission needs grading
- to students when the submission is graded
- to students when the grade changed
this one is very difficult to reproduce manually. data needs to be in a state
where a delayed job has been queued to send a notification message for a quiz
submission before the namespace change was deployed, and then it attempts to
execute the delayed job after the namespace change. it appears that messages
are only sent to a delayed message queue when there there are more than 500
messages per day.
Change-Id: I0869b4decaec900a2c4c8df5c6e0b8b29dd08c5c
Reviewed-on: https://gerrit.instructure.com/33307
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Josh Simpson <jsimpson@instructure.com>
QA-Review: Caleb Guanzon <cguanzon@instructure.com>
Product-Review: Derek DeVries <ddevries@instructure.com>
instead of attempting to load the passed
DelayedMessage records whatever happens to be the
current shard
fixes CNVS-4568
test plan: specs should pass
Change-Id: I585e1bfb87be160608f7ae4f4c8f8f97d260ff69
Reviewed-on: https://gerrit.instructure.com/28366
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Anthus Williams <awilliams@instructure.com>
Product-Review: Anthus Williams <awilliams@instructure.com>
QA-Review: Anthus Williams <awilliams@instructure.com>
fixes CNVS-6280
refactors User#time_zone and Account#default_time_zone to return actual
time zone objects instead of strings.
Assignments to the fields accept both forms; reading the field prefers
to return a Rails friendly name, but the IANA name is easily accessible
from that object. Continue to use Rails names for the UI, but use
IANA names for the API.
test plan:
* in the UI, ensure that you can change timezones and it persists
correctly in the following locations:
* user profile as the user
* root account settings
* user page as an admin
* check the API responses for /api/v1/users/self/profile and
/api/v1/accounts/self; the time zone should be listed as an
IANA name (i.e. America/Denver, not Mountain Time)
* Update an account (PUT /api/v1/accounts/self) to change the
default time zone; ensure both friendly names and IANA names
are accepted on input, but on output the IANA name is returned
Change-Id: Ib976e7e1b2dde2639ff6fd478a59b38fdb0d07c0
Reviewed-on: https://gerrit.instructure.com/22563
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Cody Cutrer <cody@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>
All of the outbound email notifications have been updated to have
a matching HTML version of the email in order for us to send multi-
part emails. There has also been some tweaking of the other email
messages (summary, plain text, etc) with a better looking layout
fixes CNVS-4728
fixes CNVS-4795
test steps:
- generate email messages for each template and review the results
in the users message list view (/users/1/messages)
Change-Id: I1fd9cf2b134209e42c8d174f19b50963e6502f6a
Reviewed-on: https://gerrit.instructure.com/18942
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
Product-Review: Eric Berry <ericb@instructure.com>
fixes CNVS-3917
the notifications table had vestigial `body` and `sms_body`
columns that canvas no longer uses. this commit drops those
columns.
test plan:
* back up your database (unless you want to keep this
commit on your master branch forever);
* run migrations;
* verify that notifications still send as expected;
* for extra credit, configure canvas with a new database
and verify that db:initial_setup still works without
any errors.
Change-Id: Icc7d8c4e926b5ea0ecb8c3814fdc95481037a0c9
Reviewed-on: https://gerrit.instructure.com/17892
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
Reviewed-by: Mark Ericksen <marke@instructure.com>
fixes CNVS-1714
test plan:
* do an action that goes through DelayedMessage.summarize
(I think just means setting some notifications to every 5 minutes
or something)
* wait the five minutes
* the message(s) should show up in /users/x/messages
Change-Id: Ibcc646f9ec869543b8ba84c1d7c7f8171ce55d78
Reviewed-on: https://gerrit.instructure.com/17166
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
notifications were happening on monday because
TimeWithZone.advance(:days => x) does nothing. move them to saturday for
real and also spread them over the Eastern-time day instead of lumping
them all at 8pm (admittedly by timezone, but that's only 4 hours for the
continental US, which is the current majority of users).
add an indicator to the notification preference page to show a rough
time block in which they can expect their weekly messages to be sent.
fixes#8296
test-plan:
setup:
- create two accounts the same id but on different shards (shard ids
should not differ by a multiple of four)
- in each a account, create a user with a communication channel; call
them Alice and Bob.
- create a third account on the same shard as Bob's account but with a
different id (account ids should not differ by a multiple of four)
- in this account create two users with a communication channel each;
call them Charles and David.
- for each of the four users, assign a notification to deliver to the
user's communication channel weekly
- on Friday, trigger the associated notifications for each user
- on Sunday, trigger David's notification again
expectations:
- each user should receive the messages on saturday (Eastern-time),
not monday
- Alice's and Bob's emails should arrive in different "quarter days"
- Bob's and Charle's emails should arrive in different "quarter days"
- Charles' email and David's first email should arrive in the same
"quarter day" but in different hours
- David's emails should come a week apart, but in the same hour both
times
UI:
- go to the notifications preference page
- should see note at bottom indicating two hour block during which
their weekly notifications will be sent
- actual send time of weekly notifications should fall within that
block
Change-Id: I97bb75762ef8c03fae99ad5499b441f7c026d2c8
Reviewed-on: https://gerrit.instructure.com/13963
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
test plan:
* use canvas and ensure that notifications work
Change-Id: Ie46f049aab5dde7167c3ea4228e503c7a686c839
Reviewed-on: https://gerrit.instructure.com/9154
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
* trying to auto assign peer reviews for an assignment that never had,
or no longer has, a due_at
* trying to process a delayed message for a context that has already
been deleted since the job was scheduled
Change-Id: I090252a07cd616918bf664a326c33772aa3893dd
Reviewed-on: https://gerrit.instructure.com/4312
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Joel Hough