fixes CNVS-14383
test plan
- create a discussion with "post before seeing replies" checked
- create a reply to the discussion
- as a user in the course who has not replied to the topic,
fetch the /api/v1/courses/:course_id/activity_stream/summary
- as the topic creator, edit the topic message (to queue a job
to recreate the materialized view)
- ensure that the reply is still present (the materialized view
must be regenerated before the bug would remove the entry)
- toggle the unread state on the entry, ensuring that no errors
appear in the debug console
Change-Id: Iaf8d15195c5c6fef8f1b22bf7dfc9110b05394f2
Reviewed-on: https://gerrit.instructure.com/38564
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Matthew Wheeler <mwheeler@instructure.com>
Reviewed-by: Mark Severson <markse@instructure.com>
Product-Review: Matthew Wheeler <mwheeler@instructure.com>
QA-Review: Steven Shepherd <sshepherd@instructure.com>
This was a beta api that didn't work out.
Test plan:
canvas should still work (sorry, this touches lots of stuff)
Change-Id: I31680b83f72f6d739ce74735ba40d7a760debb33
Reviewed-on: https://gerrit.instructure.com/29506
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
QA-Review: Caleb Guanzon <cguanzon@instructure.com>
Product-Review: Cameron Matheson <cameron@instructure.com>
1. make sure the returned stream item ids are relative to the user, not
the domain, since we need to look up the instances by those ids from
the user's shard later
2. make sure we actually handle shortened global ids, rather than
asploding
3. just cache stream items on the user's shard, not on every shard the
user visits. makes cache invalidation practical/possible
test plan:
1. set up canvas with redis and sharding
2. set up two additional shards (your user is in the initial/primary one)
3. enroll your user in a course in the second shard
4. as another user, do something that creates a stream item for the course
(e.g. create an announcement)
5. as the original user, confirm that:
1. you see the stream item on your shard's dashboard
2. you can dismiss the stream item
3. when you refresh the page, it is still dismissed
6. repeat step 4.
7. as the original user, confirm that:
1. you can see the stream item on the shard 3 dashboard
2. you can dismiss the stream item
3. when you refresh the page, it is still dismissed
8. as the original user, confirm that the items are dismissed from your
dashboard on all shards
Change-Id: I2c600685015640af36d9e33ac71e25cd536d7391
Reviewed-on: https://gerrit.instructure.com/24155
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Mark Ericksen <marke@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
Apparently the fact that a shared example group added its before/after
filters to the outer context was a bug, and it's been fixed in rspec 2.
So we can't use a shared example group to setup or mark pending sharding
specs anymore.
test plan: specs
Change-Id: I92b022e2e7125214e6bad38bf0a23da547fca984
Reviewed-on: https://gerrit.instructure.com/19182
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Duane Johnson <duane@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
QA-Review: Brian Palmer <brianp@instructure.com>
two major pieces:
* use context_type/context_id instead of context_code for
three relations so that sharding extensions will
automatically work
* deserialize stream item data as actual AR objects instead
of OpenObject (for similar reasons)
test plan:
* run the predeploy migration, but not the postdeploy one
* view your dashboard on a shard other than your home shard;
it should be identical to your home shard
* view courses that you are enrolled in with the same id but on
different shards. the activity stream should have the correct
data for the course in that shard, for both courses (i.e.
no mixing of data from the two shards)
* do actions that generate new stream items, and verify the new
items appear correctly for the above two steps
* run the postdeploy migration, wait for the job to finish, then
repeat the test plan
Change-Id: I8d5fcadb8d971acf7388a12e9151a3e927751f44
Reviewed-on: https://gerrit.instructure.com/15462
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes#11087
test plan:
- manually run StreamItem.destroy_stream_items_using_setting
- it should work
- you should not have stream items over a month old (you might be able to see
this on a user that hasn't had any activity in the last month)
Change-Id: I64ae4458d18295537daeaf08cd131aea4d01091b
Reviewed-on: https://gerrit.instructure.com/14131
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Create upvotes in the upvoting user's shard, so we can query for them,
and make the upvote_count and post_count cached counts update properly
cross-shard.
Remove a foreign key constraint that was preventing users on other
shards from posting items to a collection.
Create stream_item_instances on the user's shard, and make sure to query
them from there.
Further work should be done to optimize :include so that we can
efficient pull in the stream items for the instances.
test plan: as a user on one shard, interact with a collection on another
shard -- posting to it, upvoting/downvoting, cloning items from that and
other shards. verify you don't get errors, missing data, or incorrect
counts.
Change-Id: I91aeebd404cd20663a533b2f38c08ec90c65868e
Reviewed-on: https://gerrit.instructure.com/11228
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
They weren't using the course/group for the context_code, so they would
only show up in the global stream.
Note this doesn't fix existing stream items, just new ones going
forward.
test plan: add an assignment or generate any other sort of notification
that gets sent to the stream. verify that it shows up both on the
dashboard and on the individual course/group stream.
Change-Id: Icfa1430545e80c575c76960a7267ae1d7d8ddad4
Reviewed-on: https://gerrit.instructure.com/10842
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes#8403
test plan:
* import an external content package with discussion topics
* make sure to find a discussion topic that has no author
* on the dashboard of a user that has a stream item about that topic
it should not show that the current user is the author
Change-Id: I681be31462a82591d60665dce967aa1548ef3a07
Reviewed-on: https://gerrit.instructure.com/10579
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Joel Hough