fixes VICE-3556
flag=none
requires MRA
Test PLAN:
0)
For SPEC Test
b. use the below to run the spec
RAILS_LOAD_CANCEL_PENDING_DUPLICATE_MESSAGES=1 bundle exec rspec spec/lib/notification_message_creator_spec.rb:746
For UI Test
a. go to: lib/notification_message_creator.rb:84
replace immediate_policy?(user, channel) to true
setup:
Have two shards A,B.
Have a courseA on shard A.
Have a userB on shard B.
Enroll the userB on courseA.
Create an assignmentA on courseA.
-- make it /3 or a number *important
Create submit an answer on assignmentA.
1) go to grade assignment A <= 3.
ex: /courses/1/gradebook/speed_grader?assignment_id=1&student_id=20000000000001
-- if you go above it may trigger
'Submission Grade Changed' which is the incorrect notification.
a) change grade many times.
2) go to /users/userB.user_id/messages
ex: /users/20000000000001/messages
3) See that all are cancelled except 1 staged.
-- 'Submission Graded'
Notes:
Why duplicate messages are being created.
1. Sharding, messages are not being searched on the users shard.
-- this ticket fixes.
2. graded_recently? is used incorrectly
- submission_graded should follow submission_grade_changed and use
!graded_recently? for whenever clause.
3. submission_graded && submission_grade_changed notifications are used incorrectly
submission_graded && submission_grade_changed notifications can both be
called during regrade process. submission_graded should only be called for the
first grade.
Change-Id: Idd6075527ec4a43b43f3e57b52601eb4715478aa
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/320275
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Drake Harper <drake.harper@instructure.com>
QA-Review: Caleb Guanzon <cguanzon@instructure.com>
Product-Review: Caleb Guanzon <cguanzon@instructure.com>
[skip-stages=Flakey]
Change-Id: I6abefdfa9fed6dd4525c8786e93efa548b3710f2
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/319603
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Isaac Moore <isaac.moore@instructure.com>
QA-Review: Jacob Burroughs <jburroughs@instructure.com>
Product-Review: Jacob Burroughs <jburroughs@instructure.com>
Build-Review: Jacob Burroughs <jburroughs@instructure.com>
Migration-Review: Jacob Burroughs <jburroughs@instructure.com>
fixes VICE-1507
flag=deprecate_sms
test plan:
- cursory testing around notifications:
- account notifications preferences page should load without any
sms channels
- course notifications preferences page should load without any
sms channels
- notifications can still be sent for other channels
qa risk: low
Change-Id: Ibfa0c4f404f50e9a88960b26bc367a2ea8acee12
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/272590
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Caleb Guanzon <cguanzon@instructure.com>
Product-Review: Caleb Guanzon <cguanzon@instructure.com>
Reviewed-by: Caleb Guanzon <cguanzon@instructure.com>
We need to get the account's timezone to be used as a default in
the event that the user has a null timezone set.
fixes VICE-1794
flag=none
Test Plan:
- Set the account timezone to something besides mountain time
e.g. Alaska is what I used in testing
- Set a user's timezone to null. I just grabed the user in a rails
console and updated User.find(<user_id>).update!(time_zone: nil)
- Enroll the user in a published course
- Create an assignment with a due date or another event that will
trigger a notification with a specific time in the message body
- Check the users messages and note that the due date should reflect
the accounts timezone
/users/<user_id>/messages
Change-Id: Ib7787a424dc75c231da4f859e44f14a4a29f8914
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/271904
Reviewed-by: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
when our context is an assignment we currently are loading a
rubric_association to identify the root_account
test plan
- specs should pass
fixes VICE-1280
flag = none
Change-Id: I9d9493da1d80cb8208e999619700f657a8c00bca
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/263328
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Tested-by: Mauricio Ribeiro <mauricio.ribeiro@instructure.com>
Reviewed-by: Mauricio Ribeiro <mauricio.ribeiro@instructure.com>
QA-Review: Mauricio Ribeiro <mauricio.ribeiro@instructure.com>
Product-Review: Mauricio Ribeiro <mauricio.ribeiro@instructure.com>
we preload all the notification policies, so we want to use find instead
of a query to check for fallback channels
test plan
- specs should pass
refs VICE-1280
flag = none
Change-Id: I963610d6cf76236e4a69f33f52932694c9751984
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/263325
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Omar Soto-Fortuño <omar.soto@instructure.com>
QA-Review: Omar Soto-Fortuño <omar.soto@instructure.com>
Product-Review: Omar Soto-Fortuño <omar.soto@instructure.com>
closes FOO-1405
TEST PLAN:
1) get several jobs trying to send the same
kind of notification to the same user at the same time
when they don't currently have a policy for that user
2) only one policy gets created, and all jobs use that policy
without throwing any errors
Change-Id: Ib5b8b8348d5f4e928724aad9c4a49a844c19dbf8
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/255975
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
appointments are actually calendar events that can and do belong to many
courses. If a user has a notification preference in any of the courses,
we will respect that preference.
test plan
- it should set course_ids and respect notification preferences
fixes VICE-983
flag=none
Change-Id: I4ccaaab541eb92599f4e1ca1fb63f1930556a8d5
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/253226
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Caleb Guanzon <cguanzon@instructure.com>
QA-Review: Caleb Guanzon <cguanzon@instructure.com>
Product-Review: Caleb Guanzon <cguanzon@instructure.com>
test plan
- specs should pass
fixes VICE-998
flag=mute_notifications_by_course
Change-Id: I2dc572a8013817bd1e3ae2ace54e52932e463cdd
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/254038
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Matthew Lemon <mlemon@instructure.com>
Product-Review: Matthew Lemon <mlemon@instructure.com>
QA-Review: Matthew Lemon <mlemon@instructure.com>
communication_channels only live on users shard and they only work on
users shard. There have been bugs that were incorrectly placing them on
a different shard, but they never worked.
users invited into a course get a user object created as pre-registered,
but they do not get root_account_ids set until after they have clicking
the email. the email can also cause a user merge that would put the
communication_channel on the merged user but again the root_account_ids
would not be present until after that process so before_create was not
enough to populate communication_channels.
this commit also makes it so the channels are just populated on a user
merge event, since they could change, this is also appropriate.
after a datafix up is run ids should be populated but log a stat when we
send a message to ensure it.
fixes VICE-895
flag=none
Change-Id: I4721a563988f8fa399fca9d23b73e17c2a6371e7
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/249227
Reviewed-by: Matthew Lemon <mlemon@instructure.com>
QA-Review: Matthew Lemon <mlemon@instructure.com>
Product-Review: Matthew Lemon <mlemon@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
the schema may not exist that we are trying to query
Change-Id: I3ca987fd31a1e230b9fdec30cf04c7b8c05f01df
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/246496
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
test plan:
* current specs exercise both queries
Change-Id: I61d9f3bb6e6758fcc895332ccd9687a13b40b894
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/245975
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
Test Plan:
-navigate to /accounts/<user id with admin access>/settings
-add an admin by email
-navigate to /users/<new user id>/messages
-verify there is an message for
flag=none
fixes VICE-573
Change-Id: I5f3f5b4bae657a5449836cddc525310bef3e8682
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/244801
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
communication channels can be set to a bounced state for a temporary
problem and maybe restored after some time. When a communication_channel
gets in a bounced state, immediate messages to it would not get saved,
but delayed messages would. This commit changes immediate messages to
still be created in a bounced state, but not be sent. This is
informational only and is similar to a canceled message. When possible
we still create a new delayed message for the notification. Then when
the channel is no longer bouncing, they will get all the delayed
messages in the next summary. Messages regarding registration will not
create a delayed message, but they will still be in the bounced state to
easier verify if a message was sent or not.
test plan
- specs should pass
fixes VICE-654
flag=none
Change-Id: I4810636f0d82a372799942fd1c2f473587900c8f
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/243709
Reviewed-by: Matthew Lemon <mlemon@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Matthew Lemon <mlemon@instructure.com>
Product-Review: Matthew Lemon <mlemon@instructure.com>
this changes how we process user_channels in the file, this will iterate
over all the applicable channels per user instead of iterate over users.
this also makes it so notification policies are looked up in the same
method for each type of message
test plan
- specs should pass
flag=none
fixes VICE-414
Change-Id: I43416151567950a43da4b309f4a9fffb28a4a048
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/242213
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Matthew Lemon <mlemon@instructure.com>
QA-Review: Matthew Lemon <mlemon@instructure.com>
Product-Review: Matthew Lemon <mlemon@instructure.com>
This is just a few comments and logging some new statistics to see how
some of this is currently used.
test plan
- specs should pass
flag=none
refs VICE-414
Change-Id: I6f003f9213722a9662c258e545f8afaf1ccdb650
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/242211
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Matthew Lemon <mlemon@instructure.com>
QA-Review: Matthew Lemon <mlemon@instructure.com>
Product-Review: Matthew Lemon <mlemon@instructure.com>
this particular code was added to message creator when processing
messages was moved from notifcation.rb. When it was brought over it was
broken because it was assigning the message to daily instead of checking
for daily. This was later fixed because in a commit that was for
reducing memory usage.
delayed_messages is delayed_messages for all users passed into the
message_creator at that time, and this should not be used to determine
if a fallback message should or should not be sent.
Test plan
- specs should pass
flag=none
refs VICE-414
Change-Id: I10f12d4d8a84984ddf46679b793f8e7db7cfb1f5
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/240337
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Matthew Lemon <mlemon@instructure.com>
Product-Review: Matthew Lemon <mlemon@instructure.com>
Reviewed-by: Matthew Lemon <mlemon@instructure.com>
test plan
- specs should pass
several tests were added and there are many tests for this file, we just
want them all to pass. There should be no change in functionality.
flag=none
refs VICE-414
Change-Id: I9c3cdd73706b780dc8578db7651e827e6a2e66f4
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/240336
Reviewed-by: Davis Hyer <dhyer@instructure.com>
QA-Review: Davis Hyer <dhyer@instructure.com>
Product-Review: Davis Hyer <dhyer@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
test plan
- specs should pass
several tests were added and there are many tests for this file, we just
want them all to pass. There should be no change in functionality.
flag=none
refs VICE-414
Change-Id: Ic9fce60499826da7852a9d49f0c0e875ee950633
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/236242
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Drake Harper <drake.harper@instructure.com>
Reviewed-by: Matthew Lemon <mlemon@instructure.com>
QA-Review: Drake Harper <drake.harper@instructure.com>
Product-Review: Drake Harper <drake.harper@instructure.com>
test plan
- send a message
- message should send
- specs should pass
- should not send duplicate messages
flag=none
fixes VICE-506
fixes VICE-538
Change-Id: Ief7f09db4fdfc78864be9a537902e6863b1e0858
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/240227
Reviewed-by: Matthew Lemon <mlemon@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Matthew Lemon <mlemon@instructure.com>
Product-Review: Matthew Lemon <mlemon@instructure.com>
fixes KNO-526
test plan:
- feature only works when flag is turned on
in the site admin level
Change-Id: I8e4f7669606498d61c327d3a352c4533c0c08179
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/239378
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
fixes KNO-502
flag=none
/ ---- ---- \
| Test Plan |
\ ---- ---- /
- Create a user and add several communication channels to them
- Confirm all the communication channels but one
- Create a course and add the user to it
- Update the users notifications preferences to immediate for all
preferences and channels
- Create a notification
- As an admin navigate to /users/<user_id>/messages
- Note that there should only be a new message sent to active
communication channels
Change-Id: Ib5937526e881ea455addb3e4a173bea19e924d34
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/237910
Reviewed-by: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Allows course context notification preference overrides to actually take
effect when creating notifications for a user.
fixes KNO-402
flag=notification_granular_course_preferences
/ ---- ---- \
| Test Plan |
\ ---- ---- /
- Run the following migration
bundle exec rake db:migrate:up VERSION=20200420211742
- Create two courses and add a student and a teacher to it
- configure a communication channel for the student
- As the student create a notification preference override for
announcments with an immediate frequency for the first course
- This can be done through graphiql using the following mutation
```
mutation MyMutation {
__typename
updateNotificationPreferences(
input: {
contextType: Course,
communicationChannelId: <communication_channel_id>,
courseId: <course_id>,
frequency: immediate,
notificationCategory: Announcement
}
) {
course {
_id
notificationPreferences {
channels {
_id
path
pathType
notificationPolicies {
communicationChannelId
frequency
notification {
category
categoryDisplayName
name
}
}
notificationPolicyOverrides(
contextType: Course,
courseId: <course_id>
) {
communicationChannelId
frequency
notification {
category
categoryDisplayName
name
}
}
}
}
notificationPreferencesEnabled
}
}
}
```
- As the student navigate to /profile/communication and set all your
Announcement policies to 'weekly'
- As the teacher navigate to the SECOND course and create an
announcement
- Navigate to /users/<student_id>/messages and note that the
announcement notification should not exist
- In a rails console check that the DelayedMessage was created
n = Notification.where(category: 'Announcement').first
delayed_messages = DelayedMessage.where(
notification_id: n.id,
communication_channel_id: <channel_id>
)
- The delayed_messages array should contain the notification for the
announcment with a 'weekly' frequency
- As the teacher navigate to the FIRST course and create an announcement
- Navigate to /users/<student_id>/messages and note that the
announcement notification should exist
- In a rails console validate that the DelayedMessage was not created
using similar steps as detailed above
- Now as the student set your override policy to 'daily' using the same
mutation provided above but changing the frequency
- navigate to /profile/communication and set all your Announcement
policies to 'immediately'
- Run the same tests as above but now validate that an immediate message
is created for the second course when an announcment is created and no
delayed message is created
- Also verify that a delayed message with a 'daily' frequency is created
for the first course when an announcement is created and no immediate
message is created
- phew, that was a doozy of a test plan!
Change-Id: Idb5e95bf13762472c3fdd7aceef200a17f5cd9a0
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/234804
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
QA-Review: Ahmad Amireh <ahmad@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
The small refactor made to this file ended up introducing an unnecessary
query which we are removing here.
refs KNO-409
flag=none
/ ---- ---- \
| Test Plan |
\ ---- ---- /
- Tests pass
Change-Id: Iee116f1d87c39b2c129b90cc7ed4bab964b9095b
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/234952
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
Fixing up notification_message_creator a little bit in preparation for
adding notification_policy_overrides to the notification creation
process.
fixes KNO-409
flag=none
/ ---- ---- \
| Test Plan |
\ ---- ---- /
- Tests pass
Change-Id: I83ce9aa58ebf9bd79c00578e0e24352d34f803c2
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/234413
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
QA-Review: Ahmad Amireh <ahmad@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
localize recent message count management into one place, and populate it
beforehand to allow a single DB query for all users not already in the
cache. using a single DB query removes the need for the redis caching
Change-Id: Ic0d58f820628742cbb92fc8fab075d1c57b9fb66
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/231282
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
DelayedMessage#set_send_at is called as a before save, and calls both:
- self.communication_channel
- self.communication_channel.user
Meaning that each time a delayed message is saved, it generates a query
for a communication channel and a user.
One common place delayed messages are created is in the
NotificationMessageCreator. at the time they are created the
communication channel and user are already in memory, we just need to
coax rails into using them.
Rails tries to set inverse_of associations automatically whenever
possible, but it appears that something (maybe the order argument) on
user.communication_channels is preventing that from happening. Once we
have inverse associations working properly, we can pass the object
instead of the id so everything is preloaded.
As noted in the inline comment, this is safe because notification_policy
is always loaded from a communication_channel association, whose
automatic inverse_of association is working correctly.
test plan:
- send a delayed notification to many people
- it should work, and not over-query communication_channels or users
Change-Id: Ia24282c9a24746701227781b4782b22b6c9f70f7
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/231352
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
flag=none
test plan
- spec should pass
Change-Id: I4f7839410ed6f3878c6dc71ff74eb510d20b8142
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/229513
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ben Nelson <bnelson@instructure.com>
QA-Review: Ben Nelson <bnelson@instructure.com>
Product-Review: Ben Nelson <bnelson@instructure.com>
when a user disables notifications for a course, we should not send them
notifications. this commit checks for the policies set course_id and
skips when the user has disabled notifications for the course.
Other commit will verify the set_policy blocks are all setting the
course_id
test plan
- set a notification preference to disabled for a course
- trigger notification
- the user should not get the notification
flag=mute_notifications_by_course
qa risk: low, it's a new controller also, it is behind ff
closes KNO-224
Change-Id: I1c8de3060f31b2bc4914ed4b729bd494f9059674
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/228293
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Johnny Le <jle@instructure.com>
Reviewed-by: Johnny Le <jle@instructure.com>
Product-Review: Johnny Le <jle@instructure.com>
test plan
- specs should pass
fixes KNO-237
Change-Id: Ibea4ee22359fda8e3b11b50ce9ce7a2d6c939761
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/227682
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Davis Hyer <dhyer@instructure.com>
QA-Review: Davis Hyer <dhyer@instructure.com>
Product-Review: Davis Hyer <dhyer@instructure.com>
test plan:
* create a user in a course with a confirmed email
* as that user, view the notificatio settings and
override a testable notification type
(e.g. Announcements) to send later (daily/weekly)
* override another type to send immediately
* test the notification (e.g. add an announcement
to the course)
* should not send the notification right away
closes #CORE-2815
Change-Id: I8930d1ff4142a5128224023bcdfdcf9c2458bcc0
Reviewed-on: https://gerrit.instructure.com/190165
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
Tested-by: Jenkins
Change-Id: I2adcced2aa8db70828c2943a004525eaef267a37
Reviewed-on: https://gerrit.instructure.com/185626
Tested-by: Jenkins
Reviewed-by: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
test plan:
* run the following in a rails console:
Account.default.tap do |a|
a.settings[default_notifications_disabled_for_observers] = true
a.save!
end
* use a sis batch import with user_observers.csv to create
an observation link for a student and observer
* as the observer, view the "Notifications" section of their
account settings
* they should all default to "Never"
closes #COMMS-1898
Change-Id: Iabf5bff42efa521bdad34ccf7de277cee0e1789c
Reviewed-on: https://gerrit.instructure.com/184022
Tested-by: Jenkins
Reviewed-by: Landon Gilbert-Bland <lbland@instructure.com>
Reviewed-by: Steven Burnett <sburnett@instructure.com>
QA-Review: Steven Burnett <sburnett@instructure.com>
Product-Review: Steven Burnett <sburnett@instructure.com>
Change-Id: Id6da71dd0655cded67b61315ef63a488abe0b579
Reviewed-on: https://gerrit.instructure.com/178808
Tested-by: Rob Orton <rob@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
Jacob Burroughs