fixes a problem where context stream items were not being
invalidated correctly for rails 3
test plan:
* set up an environment with a server running with rails 3
and delayed_jobs running with rails 2, and a redis cache store
* create a published course with an active student
* create an publish a new assignment
* confirm that the "recent activity" dashboard on the course
shows the new assignment message for the student
fixes #CNVS-13205
Change-Id: I763d0d09c0c4b092b740f8b7a1e374cd954a5f16
Reviewed-on: https://gerrit.instructure.com/36034
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Strong <clare@instructure.com>
Product-Review: Clare Strong <clare@instructure.com>
dashboards don't show these, and existing ones can be a little crazy if
they have lots of submission comments
also change cache key so these get regenerated
test plan:
1. dashboards should work
2. stream item api should work
3. specs should pass
Change-Id: I245f4464189a507f0e1a8c9dc1c4c1e9fd4b7566
Reviewed-on: https://gerrit.instructure.com/16502
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Cam Theriault <cam@instructure.com>
refs #CNVS-1291
break out of single record by record creation
and use bulk insert instead (also
had to take into account replicating
observer and lifecycle event behavior that was
declared elsewhere)
TEST PLAN:
Go to a large course and take some action
that generates stream items for all the students.
It should not take nearly as long now.
Change-Id: I8f40ccdcfc81e6edb44ac3b245d254b9376dd3b2
Reviewed-on: https://gerrit.instructure.com/15874
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ethan Vizitei <ethan@12spokes.com>
QA-Review: Clare Hetherington <clare@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>
it's a common query, so reduce db dependency if possible
test plan:
* as a site admin, ensure you still have access to everything
* as a non-site admin, ensure you don't have access to any courses
or accounts that you shouldn't (even without links to them)
Change-Id: I56fb5063b16fe6a3ddc96bdf66586a9e48a79850
Reviewed-on: https://gerrit.instructure.com/13757
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
refs #9679
Often we already have the user loaded. Sometimes we don't, like when
displaying a stream item where only the user id is serialized to the
data blob. In these cases, we load the user now. This can make the
request slightly slower, but that's still more optimal than making
another separate request that loads the user.
test plan: avatars should still display as expected throughout the app,
but the urls canvas puts in the html will change -- they will directly
point at the image url now, rather than going through /images/users/XX
Change-Id: I418b81ee59aecd0ffd0c55c8ac305b77115f464e
Reviewed-on: https://gerrit.instructure.com/13061
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Brian Palmer <brianp@instructure.com>
fix regression from #5618 where we stopped passing along the fallback
for conversation avatars.
also fixed it so we always respect the fallback, host/scheme, and
domain account avatar setting. previously we would cache the first one
for a given user, to the detriment of any subsequent requests for that
user (e.g. conversations uses the default fallback for the recipient
finder, and a custom one for everything else. without this change,
whichever one got requested first would win and get cached as the
gravatar fallback).
test plan:
setup:
* make sure you have avatars set up on various users (some submitted,
some approved)
stuff from #5618:
* make sure the old style of avatar image urls still work
* go to a page with user avatars (like discussions)
* make sure avatars appear correctly for users with avatars
* put in a bogus URL ("/images/users/a")
* make sure it doesn't die
* put in a bogus URL with a hyphen ("/images/users/1-1")
* make sure it doesn't die
then test conversations:
* go to conversations with avatars enabled
* ensure that you see the appropriate gray silhouette for users
without a gravatar in the conversation/message panes
* ensure you see the alternating gray/white silhouette (depending
on focus) for those users in the recipient finder (it's actually
the blank image, the silhouette is a background image behind it)
then test hostname and account setting fu:
* log in under a different domain (e.g. 127.0.0.1 instead of
localhost) and go to discussions
* ensure that the fallback image is served up from the current domain
* change the avatar setting to enabled_pending
* ensure that you only see approved avatars (see initial setup)
then test cache invalidation:
* approve a pending avatar
* ensure the avatar now shows up under all domains
Change-Id: I9cd007463e3cb4a302b1986f9d4bb61fe16799ac
Reviewed-on: https://gerrit.instructure.com/9130
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
testplan: with rails caching enabled, change a user's avatar settings to
(a) a different service or (b) a different image url. verify that the
change is immediately visible, rather than having to wait 30 min.
Change-Id: I03c63a0e5a2cccd59ed8d9f324d2e391b46c4675
Reviewed-on: https://gerrit.instructure.com/5284
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
James Williams