This will insure that all the IDs returned from the materialized view
(`/api/v1/courses/<id>/discussion_topics/<id>/view`) will properly use
the global or local ids for all fields, depending on what shard is
currently activated (ie what shard the request came through).
In 99% of cases this will have no affect, because the request will come
from the same shard that holds the materialized view and this everything
is properly relativized already. It only affects cross shard instances.
Fixes COMMS-1496
Test Plan:
* Setup sharding locally
* Create a course on one shard that has a discussion, with a student
in that shard having replied to the discussion
* Enroll a student from another shard and also have them reply to the
discussion
* Access the endpoint from both shards, something like:
- shard2.canvas.test/api/v1/courses/1/discussion_topics/5/view
- shard3.canvas.test/api/v1/courses/2~1/discussion_topics/2~5/view
* Verify in the local shard all the ids are local ids except for the
student who replied from the other shard, who should have a global
id. This should be true in both the `participants` key and the
`view` key of the resulting json
* Verify in the remote shard all of the ids are global ids, except for
student who replied from this shard, who should have a global id.
Change-Id: I94a3c848b2ed0722f9bb17d4d613353466cdd138
Reviewed-on: https://gerrit.instructure.com/169048
Tested-by: Jenkins
Reviewed-by: Steven Burnett <sburnett@instructure.com>
QA-Review: Landon Gilbert-Bland <lbland@instructure.com>
Product-Review: Landon Gilbert-Bland <lbland@instructure.com>
f10280169f