just regenerate the data stored on the stream item itself
test plan:
* send a message to two other users
* as one user, hide the conversation stream item
on the dashboard
* as the other, delete the message in the inbox
* the stream item should not have reappeared
closes #COMMS-1812
Change-Id: I9338c56bb5c26d3585452879b83dee5c64a497bb
Reviewed-on: https://gerrit.instructure.com/175996
Tested-by: Jenkins
Reviewed-by: Steven Burnett <sburnett@instructure.com>
QA-Review: Steven Burnett <sburnett@instructure.com>
Product-Review: Steven Burnett <sburnett@instructure.com>
Fixes COMMS-1139
Test Plan:
- Send a new conversation to your main user
- Using https://lti-tool-provider-example.herokuapp.com/xml_builder,
create a new collaboration. Set the collaboration section to
content_item_selection_request
- Go to http://localhost:3000/api/v1/users/self/activity_stream and
verify that the message for the collaboration object is the collab's
description.
- Also verify that the title of the conversation object is the subject
Change-Id: If1fecd634ecf3e3af89055b5e0f958c83f419d27
Reviewed-on: https://gerrit.instructure.com/155673
Tested-by: Jenkins
Reviewed-by: Landon Gilbert-Bland <lbland@instructure.com>
QA-Review: Steven Burnett <sburnett@instructure.com>
Product-Review: Sara Chadwick <schadwick@instructure.com>
also do it 4x daily rather than 1x daily
Change-Id: I328091586226e334c48bfe96b57b0a601bb22ef2
Reviewed-on: https://gerrit.instructure.com/143678
Tested-by: Jenkins
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
test plan:
* add a rubric to a course
* update the course's course code
* use the "find rubric" to add an existing
rubric to an assignment
* the course code listed on the left side
should match the new course code
closes #OUT-1781
Change-Id: Iebc77716ecfef90ae9e099367c2305314dbf265e
Reviewed-on: https://gerrit.instructure.com/136576
Tested-by: Jenkins
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Andrew Porter <hporter-c@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
fixes COMMS-246 COMMS-500
test plan:
- create a graded discussion in a course with at least two students
- post in the discussion as the teacher
- without viewing the notification, check the dashboard as each of the
students and make sure each have 1 discussion notification
- as the teacher, assign that discussion only to the first student
- as the first student check your dashboard and note you still have
that notification
- as the second student check your dashboard and note you no longer
see that discussion notification or the discussion itself
- as the teacher make another reply on that discussion
- as the second student note that you don't see a new discussion
notification or the discussion itself on the dashboard
Change-Id: If5af3878d9e995479b959d799f6ebd7e82a1d14a
Reviewed-on: https://gerrit.instructure.com/132037
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Venk Natarajan <vnatarajan@instructure.com>
QA-Review: Heath Hales <hhales@instructure.com>
Product-Review: Felix Milea-Ciobanu <fmileaciobanu@instructure.com>
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>
James Williams