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>
* 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>
Cody Cutrer