fixes CNVS-29235
Test Plan:
- Send all types of notifications
- Notice all dates, numbers,ect are
translated
Change-Id: Ia52a3d08ac2f5ca533439d40bc62cf4d9b53b2d8
Reviewed-on: https://gerrit.instructure.com/100380
Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com>
Tested-by: Jenkins
Product-Review: Steven Burnett <sburnett@instructure.com>
QA-Review: Steven Burnett <sburnett@instructure.com>
fixes CNVS-11838
and then choose the host more intelligently to use one the user
can actually log in to
test plan
- have accounts on two shards, referred to as "account 1" and
"account 2" from now on
- have account domains that are resolvable for the accounts,
referred to as account1.canvas.dev and account2.canvas.dev from
now on
- have account 2 trust account 1 by POSTing to
account2.canvas.dev/api/v1/accounts/<account 2 id>/trust_links
with a site admin's auth token and setting
trust_link[managing_account_id] to account 1's global id.
you can now use users from account 1 on account 2
- regression test notifications, especially considering
notifications generated by account 2 that are sent to account 1
users.
- account 1 users should have links that use account1.canvas.dev
and have global ids for referenced objects that live on
account 2's shard,
e.g. account1.canvas.dev/courses/2~1/discussion_topics/2~30
- avatars should use the avatar owner's account domain
- account 2 users should have links that use account2.canvas.dev
and have local ids,
e.g. account2.canvas.dev/courses/1/discussion_topics/30
- following the links when the user receiving the notification is
logged in should take the user to the linked object
- following the links when not logged in should take the user to
a login page that they are able to log in to
- be sure to at least check:
context file downloads links (e.g. discussion topic attachments)
file downloads links (e.g. conversation message attachments)
avatars links
conversation notifications
discussion notifications
peer review notifications
Change-Id: Idebd247fee99a2b973d3fa6f4f2fca0e723d99a5
Reviewed-on: https://gerrit.instructure.com/31867
Tested-by: Jenkins
Reviewed-by: Matthew Wheeler <mwheeler@instructure.com>
QA-Review: Steven Shepherd <sshepherd@instructure.com>
Product-Review: Joel Hough <joel@instructure.com>
closes#7036
test plan
* create a course with student teacher
* create an assignmetn with submission not graded over 7 days
* alert should happen and say why the alert was sent
Change-Id: I5ba595268d2012572c3ebba78c2bd3b286352255
Reviewed-on: https://gerrit.instructure.com/9118
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
* Daily job to evaluate alerts
* Spawns a new job for each root account (for parallelization).
It could be broken down to per-course level if needed (i.e.
if there is a *huge* root account).
* Evaluating criteria at a course level using efficient queries.
* UI for CRUD on alerts
* Render existing alerts
* Delete existing alerts
* Create a new alert
* CRUD for criteria, recipients, repetition
* Validations
* Improve instructure_helper's formErrors to support passing errors
for specific elements
* Improve Rails' :include to be able to :exclude an :include
inherited from a named scope
* Specs!!
* Note that we want to slowly roll this out, so there is a setting on
root accounts to enable it
So I ran an alert with just an interaction criterion on a test
cluster against 50,000 courses, and it took less than 10 minutes
without any parallelization. That seems like acceptable
performance to me (since there are only just over 3000 courses
in production that would even be elligible to have alerts sent
right now). Of course, that's probably skewed because I'm sure
a bunch of those 50,000 courses were essentially empty.
Change-Id: Ie028ef206c9155b9a72fb2a820f3e0e516de562a
Reviewed-on: https://gerrit.instructure.com/4799
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Steven Burnett