'all' is a scope in rails 4 that 'where' and
other methods delegate to
refs #CNVS-21596
Change-Id: I62bb115fa7158438937d1ee54c83b2e0fb17eba1
Reviewed-on: https://gerrit.instructure.com/57441
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
fixes CNVS-18976
test plan
- create communication channel
- set notification preferences to 'daily' for some notification
- cause a message of that type to be sent (i.e. queued for sending
later)
- destroy! the communication channel from the console
- ensure that the channel is destroyed
Change-Id: I10e58c9381bf9307e0fc0c5c870ccbfc24671314
Reviewed-on: https://gerrit.instructure.com/49842
Reviewed-by: Matthew Wheeler <mwheeler@instructure.com>
Tested-by: Jenkins
QA-Review: Steven Shepherd <sshepherd@instructure.com>
Product-Review: Joel Hough <joel@instructure.com>
fixes CNVS-15746
also removed some dead notification policy creation code
test plan:
* configure notification preferences through facebook
* it should work
Change-Id: Ide6e1d53767159b7946edcc23168f9683c04ee19
Reviewed-on: https://gerrit.instructure.com/44003
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-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>
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>
notification is unsharded, so it would always be on the default shard
Change-Id: I7c821ff9e8a6827708e680432ba24972a3c329ce
Reviewed-on: https://gerrit.instructure.com/39450
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
it's never used
NotificationPolicy#preference also becomes obsolete, because NOT NULL
and FK ensure that #communication_channel can never be nil; it's
also never used
Change-Id: I0669d3b89964ee6f6d4c6a62e348e276bb7ef315
Reviewed-on: https://gerrit.instructure.com/39446
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-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>
closes CNVS-5797
test plan:
* GET /api/v1/users/self/communication_channels/:id/notification_preferences
should return your preferences
* GET .../notification_preferences/<one of the named notifications returned above>
should return a single preference
* PUT .../notification_preferences/<notification>?notification_preferences[frequency]=never
should update it (will return it, and confirm by getting it again
* PUT .../notification_preferences?notification_preferences[<notification>][frequency]=never&
notification_preferences[<another notification>][frequency]=never
should update two preferences at once
* other allowed frequencies are immediately, daily, and weekly
* repeat replacing the communication channel's id by email/<email address>
* repeat by using an actual user id instead of self. users should
not be able to view or update each other's preferences. admins
should only be able to view, not update (the update routes only exist for "self",
so you'll get a 404 instead of a 401 for them)
* regression test notification preferences UI
Change-Id: I107f68a44cb68ee1675ad50ff7123e26d7765450
Reviewed-on: https://gerrit.instructure.com/26311
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
refs CNVS-4704
fake_arel gets us most of the way to rails3's arel, but with some
caveats. the workarounds (mostly) work in both, but it'll be nice to not
have them crufting around when we're on rails3. so only use the
workarounds in CANVAS_RAILS2 branches.
Change-Id: Ia1f5cfa6b10f83cdb8d9a6e397b12401d180118d
Reviewed-on: https://gerrit.instructure.com/26331
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
rather than CANVAS_RAILS3 or Rails.version
this is to be consistent, and to reinforce that any "special" branches
are for rails 2.3 backwards compatibility while trying to target rails
3, rather than rails 3 "forwards compatibility".
Change-Id: I4494b65e3f71108a43d09032c1569c478646a828
Reviewed-on: https://gerrit.instructure.com/24998
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
fixes#10422
test plan:
* set up daily or weekly notifications to an address
for a certain notification category
* delete that address
* set up a different address, and set notifications
for the same category to "never"
* make sure the notification to the old address
is not received
note that the old/new addresses could conceivably be the same
(they are in the ticket), but that's tricky to set up because
the UI will prefer to reactivate the old address rather than
create a new one with the same name
Change-Id: I908d37ae4d587afad38eb9332df4ab7c31f36f7a
Reviewed-on: https://gerrit.instructure.com/13778
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
fixes#9966
refs #9901
there was a bug where policies for non-default channels were being considered
when deciding whether a default policy needed to be created, to show on the
communication preferences page.
also prevent an exception from being thrown when a user has no communication
channels, and visits the notification preferences page. We still need some
better UI here explaining why you can't do anything on the page.
test plan:
(for #9966)
- create a new user with an email, and setup some notification preferences
- add a new email address and retire the first one
- go to the notification preferences page
- you should have default preferences for the (new) default channel
(for #9901)
- as a user with no communication channels
- go to the notification preferences page
- it should not break
Change-Id: Iecd544571d6fece2a23c24b547ae434e8b57daae
Reviewed-on: https://gerrit.instructure.com/12952
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
fixes#9942
notifications is an unsharded table, so we can't join it again notification
policies. switch to include to get expected behavior
test plan:
- on a non-default shard
- change all of your notification frequencies
- they should stay changed.
Change-Id: Ife74a2124567381e3d1898f1d34ca09904d7376d
Reviewed-on: https://gerrit.instructure.com/12937
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
When a new user visits /profile/communication, load the
system defaults for frequency settings.
Test Plan
=======
* Create a new user and visit /profile/communication.
Verify that there are default settings loaded.
* Verify that after adding a new communication channel
that defaults are not applied.
* Verify that changing a setting and reloading
preserves the user-selected value and is not
overriden by a default.
Change-Id: I9d87b316510fd08bdf40380e05b327bed7e0e95c
Reviewed-on: https://gerrit.instructure.com/12720
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Previously, the rewritten Notification's page was deleting any
entries set to "never". However, some entries and code revert to the default behavior if no setting is recorded. This just makes each "never" setting be explicitly stored if set by the user.
Testing Plan:
============
* As a student set all notifications to "Do not send me anything"
* As a teacher create a new conference
* As a teacher go to Calendar -> Scheduler -> and create an appointment group
* Check the notification messages for the student
* Ensure that the student does not receive a notification message. (/users/x/messages)
Change-Id: Idbe4ad0d8b0394217787b5684161ab5987123e60
Reviewed-on: https://gerrit.instructure.com/12706
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Refs #8066, refs #9643.
Fix notification problem where making a 'category' frequency change
did not change the settings for all the notification events in the category.
Changed notification check box text per product's request.
Added new unit-test spec for updating multiple notification settings
for the same shared category.
Testing notes:
==============
Multiple Notifications in the same category should be updated when
the category displayed is changed. For instance, "Due Date" has
two notifications in that category.
One is "Assignment Due Date Changed" and the other is "Assignment Created".
There are two different ways to verify this. One is more technical but
easier to verify. The other is all UI driven but more complicated.
Technical Approach
------------------
* Find all notification IDs in the category "Due Date":
id_list = Notification.find_all_by_category('Due Date').map(&:id)
* Find the CommunicationChannel for a given email address:
channel = CommunicationChannel.find_by_path_and_path_type('jimbo@instructure.com', 'email')
* Find the NotificationPolicy entries for the category and channel:
channel.notification_policies.scoped(:conditions => {:notification_id => id_list}).all
* Make a change to "/profile/communication" settings for "Due Date".
* Re-run the last query for listing the 2 NotificationPolicy entries. They should
both be updated to have the new frequency.
Non-Technical Approach
----------------------
* Make a change to trigger each event in the "Due Date" group. (listed above in Testing Notes).
* Verify that changing "Due Date" to a setting like "Daily" and triggering
the event that the notification is done as "Daily".
* Change the category frequency to something like "ASAP" and trigger the two events
in the category and verify that both are respected as "Immediate/ASAP".
Change-Id: I9e0473c92206b2ec43ba1c1a6a0ec4c62cdae115
Reviewed-on: https://gerrit.instructure.com/12562
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
fixes#6585, #7096
by normalizing, it's impossible to not maintain a column that isn't
there (yes, triple negative is intended in that sentence), thus
preventing sending notifications to the wrong user after a merge
or any other bugs that would have missing maintaining the
denormalization.
test plan:
* test notifications in general
* merge two active users together - their notification preferences
should survive the merge
Change-Id: I239d810c5499b94550b65128cac71c42cedd11ba
Reviewed-on: https://gerrit.instructure.com/8013
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
closes#6114
test plan:
* disable "Students can opt-in to receiving scores in email
notifications", then try to update your notification preferences
Change-Id: I47df45da741fbbc349b746c590b5d5a25feab7f5
Reviewed-on: https://gerrit.instructure.com/7040
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
This was already a small issue if the job queue was on a different
database driver than the main database, and it'll become more important
as more AR connections are introduced.
Change-Id: I204becadd32bb935df096e8c937a04bb6962f0b2
Reviewed-on: https://gerrit.instructure.com/4601
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Refs #3752 - this change alone is a 4x increase in users-per-second
import speed.
This should be safe - I looked through as much relevant code as I
could find, and it all is already defensive against policies not
being set up yet. In fact, when you initialize a blank db, the
initial user doesn't have policies set up, and they work just fine.
Change-Id: Id0e449ad0d588e83993bf83ea5536767c9166789
Reviewed-on: https://gerrit.instructure.com/3514
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Whitmer <brian@instructure.com>
Students can now opt-in to receiving actual scores
in email/sms/facebook notifications about homework
grades. This ability can be manually disabled at
the root account level if necessary.
fixes#4479
Change-Id: I1b769bef140719578fa345ca519999a2834b00f8
Reviewed-on: https://gerrit.instructure.com/3473
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
James Williams