* issueid: DS-595
* test plan:
* create assignment and submission
* update assignment and submission
* ensure appropriate messages are in the kinesis queue
Change-Id: I0d7730c8a4ec01f780ae3b77581efb7b48c2733e
Reviewed-on: https://gerrit.instructure.com/68362
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Linda Feng <lfeng@instructure.com>
refs #CNVS-25593
Change-Id: I073e1c196d8ad50818dca0bbf350e79bcfc4153b
Reviewed-on: https://gerrit.instructure.com/68940
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
fixes a problem where context stream items were not being
invalidated correctly for rails 4
test plan:
* set up an environment with a server running with rails 4
and delayed_jobs running with rails 3, and a redis cache store
* create a published course with an active student
* create and publish a new assignment
* confirm that the "recent activity" dashboard on the course
shows the new assignment message for the student
fixes #CNVS-25139
Change-Id: I555f7e082faf5d6f9d933b82cf7f7eec2d1c8fa6
Reviewed-on: https://gerrit.instructure.com/67575
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
QA-Review: August Thornton <august@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
This commit adds a new module called LiveEvents that knows how to send a
certain set of events to Kinesis. The module is configured via
normal plugin settings per account. Once the plugin is configured with
a Kinesis stream, events will start getting sent to that stream.
Events are sent asynchronously, in a background thread.
test plan:
* See `doc/live_events.md` for instructions on how to setup a local
kinesis stream and configure the LiveEvents plugin.
* Start tailing the stream with the command specified in
`doc/live_events.md` in a terminal.
* Perform the actions described in `doc/api/live_events.md` and verify
that events show up in your Kinesis terminal with the correct data.
Change-Id: Id799688c972205a1eee84a673912f84b0c7abb57
Reviewed-on: https://gerrit.instructure.com/50324
Reviewed-by: Rob Orton <rob@instructure.com>
Tested-by: Jenkins
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
Product-Review: Zach Wily <zach@instructure.com>
test plan:
* with caching enabled, create an announcement or other
object that creates items in the "Recent Activity"
* delete the item
* should refresh the activity right away and not
show the now deleted item
closes #CNVS-962
Change-Id: I28b2165c238ad074c345db23b64384439d8b8efb
Reviewed-on: https://gerrit.instructure.com/44477
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Dan Minkevitch <dan@instructure.com>
QA-Review: Jahnavi Yetukuri <jyetukuri@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
refactor everything that used to use strings for roles
to use actual role_ids
the apis should be backwards compatible so we don't need
to update (most of) the UI's right away in this commit
test plan:
* regression tests for permissions, role overrides,
alerts (for account roles), enrolling users,
adding account admins, etc.
refs #CNVS-15481
Change-Id: Id57fd3104c5c518b6fbf180609950dcddcdd474d
Reviewed-on: https://gerrit.instructure.com/41208
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Steven Shepherd <sshepherd@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
store the bare minimum of ruby objects, instead of the full AR objects
on a large site admin test object, this cache went from ~64K to ~9K
Change-Id: I102127f9344dc801be9875b7e26092857061c1f4
Reviewed-on: https://gerrit.instructure.com/40182
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Reviewed-by: Nick Cloward <ncloward@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
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>
Matt Smith