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>
e9823a9e55