nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

search.json returns illegal URL path for property thumnailLink.href

unknown

We have a problem with broken user-avatars when we mention users with @username notation on confluence pages.

The image path to the thumbnails is delivered via search.json rest method.

The propertei href for thumbnailLink is '/confluence/download/attachments/1441802/user-avatar' instead of '/download/attachments/1441802/user-avatar'.

Is /confluence/ hardcoded or cached somewhere?

We haven't configured a context path in conf/server.xml and confluence.cfg.xml.

Is it a bug or have we missed something?

Accepted answers

All comments

AnnWorley

I am not sure what the expected behavior is for the at-mentions. On the Confluence instances I am used to, there is no thumbnail of an avatar when a user is at mentioned.

Please attach a screen shot of the broken avatars to help meunderstand. At mentions on my test instance look like: Screen Shot 2017-10-25 at 12.20.01 PM.png

Thanks,

Ann

AnnWorley

Since you identified an issue with an incorrect URL, this article's resolutions may help:

Broken avatars/icons in Confluence after an upgrade due to corrupted cache

unknown

Thanks for your reply.

We already tried the three points mentioned on the broken avatar page, unfortunately the problem still exists.

The problem occurs in the editor, during autocomplete for the correct username.

The autocompleter searches for matching users, however the the thumbnailLink.href value is incorret whereas theavatarUrl is correct (see screenshot of json response).

I assume that this is a bug.

AnnWorley

Hi,

TL;DR - It worked for me after I cleared every bit of my browser history, passwords, etc. in Chrome

I tried many Confluence versions and cleared my Confluence work directory and reindexed from scratch and cleared my browsing history but the issue persisted. It was frustrating because it worked ok on our internal Production instance and on my colleagues' test instances, but not on any of my test instances. I tried with Firefox and Safari and the elusive avatar did appear! Finally I nuked all my cached Chrome elements and the avatar did appear in Chrome, too.

Here are my before and after pics, both in Chrome:

Screen Shot 2017-10-26 at 11.33.05 AM.png Screen Shot 2017-10-26 at 11.55.41 AM.png You can see in the "inspect element" that the src is user-avatar instead of default.png.

I recommend clearing your browser caches completely and trying again.

Thanks,

Ann

unknown

Thanks for the reply.

I just tested in a new virtual machine with a fresh installed chrome. The problem still occurs!

The problem is that the search request returns wrong values.

The request goes to:

https://confluence.domain.tld/rest/prototype/1/search.json?max-results=10&query=asdf&search=user&_=1509086566314

And contains a json object with a correct path to an avatar in the property result.lastModifier.AvatarUrl.href: "/download/attachments/1441802/user-avatar"

But the wrong path for the propetry result.thumbnailLink.href: "/confluence/download/attachments/1441802/user-avatar"

The rest service is not cached, so the problem lies in the backend. I haven't found a configuration option for thumbnailLink paths, so it has to be a bug.

Please create a bug request in your ticket system.

AnnWorley

Hi - I created a ticket in our support portal so we could have a closer look. The avatars appear as expected during at mentions on our test instances so we would like to examine data and environmental factors on your instance.

The support portal should email you shortly.

AnnWorley

The support engineer found a bug and created a report for it, which includes a workaround: Context path changes causes @mention avatar thumbnail to not display

If the context path is updated, the avatar thumbnail image does not display when using an @mention. Testing revealed that this applied to any user whose profile picture was created before the context path change. Problem does not occur for user profile pictures uploaded after the context path change.