Change-Id: I70825be7ec7e24458afe0c63dc48c5a76158f520
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/251150
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
Product-Review: Simon Williams <simon@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>
Closes PLAT-5801
flag=none
This change keeps the root_account_ids column
updated on the users table. Updates to this
column are triggered whenever a record in the
user_account_associations table is created,
updated, or destroyed.
Test Plan:
This test plan assumes you have MRA and at least
two shards set up.
1. Create a user and associate them with the root
account in Shard 1
2. Run jobs
3. Verify root_account_ids on the user is now an
array of size 1 containing the global ID of
the Shard 1 root account
4. Associate the same user with the root account
of shard 2 (one way to quickly do this is by
using User#associate_with_shard)
5. Run jobs
6. Verify root_account_ids on the user is now an
array of size 2 containing the global IDs of
both the Shard 1 and Shard 2 root accounts
7. Set the "sync_root_account_ids_on_user_records"
Setting to something other than "true":
```
Setting.set(
"sync_root_account_ids_on_user_records",
"false
)
```
8. Create a new user in an account
9. Run jobs
10. Verify root_account_ids is still nil
for the new user
Change-Id: Ia4b6552b887f58a85bc368312234db4da2237058
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/238830
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
Reviewed-by: Evan Battaglia <ebattaglia@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Weston Dransfield <wdransfield@instructure.com>
refs USERS-404
flag = none
when resolving the root_account_id from an Account, it is a special case
because we need to delegate to its #resolved_root_account_id property
and not the #root_account_id column as is the case with other models
in other words, instead of having to do:
through: ->(x) { x.account&.resolved_root_account_id }
you can now do
through: :account
. TEST PLAN .
...... ......
nothing outside of tests, it should be equivalent to the previous
version. OK if you insist, see the plans for g/240257 and g/240228
Change-Id: I7848f93d7c0d8cae5babd4dce0ba9a329b7c3e4b
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/240339
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Ahmad Amireh <ahmad@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
closes USERS-421
flag = none
when refreshing associations
query accounts once and set
root_account_id from that cache
TEST PLAN:
1) refresh account associations for a user
2) any new associations should get a
root_accont_id
Change-Id: I221675bd8553f121afda23644dc7af7c25e4001e
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/240257
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
refs #CNVS-32574
Change-Id: I3ba018a7110a7530c9af4a59c97422f626a749b6
Reviewed-on: https://gerrit.instructure.com/99260
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
refs #CNVS-32574
Change-Id: Idf64d7dc4272c3ee186970b994e5fec5c9597418
Reviewed-on: https://gerrit.instructure.com/94682
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@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>
refs CNVS-1338
test plan:
* run the migration on production-like data
* it should not fail
Change-Id: Ib8527f2cbee05d5e00941286f16c245091b1a2d9
Reviewed-on: https://gerrit.instructure.com/17117
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Cody Cutrer