It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,875

question asked: Jan 19 '10, 12:27 p.m.
question was seen: 10,795 times
last updated: Jan 19 '10, 12:27 p.m.

Related questions

No icon in work item list viewlet

0
Philippe Preville (36●2●8●8) | asked Jan 19 '10, 12:27 p.m.
Hello,

I just added a work item list viewlet in my web dashboard and there is no icon (neither first of second) showing in the viewlet. Someone knows what is the problem ? we have the latest RTC server 2.0.0.2

When dashboard load I see broken link icon "flashing" instead of viewing normal icon (first one is suppose to be the type of the work item, second one supposed to be the status)

2 answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Adam Archer (836●3●9) | answered Jan 19 '10, 2:11 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
There is only one cause for this that I can think of off hand. The work items services return fully qualified urls to the icons using the server's public URI root (this can be configured in the Admin UI). If the public URI of the server is not set, I'm not sure how it computes the root it uses. If the root does not match the one you are actually visiting in your browser, then you will not be authenticated and the requests for the images will fail.

A simple test to see if this is what is going on is to inspect the nodes that should be showing the images and see if the root of their src url matches the root of the url in the browser. If it does not, that is why they are not working.

In 2.x this is a known issue and to solve it you must use the web ui exclusively through the public URI root to avoid issues like this. You will likely see other problems as well if you are trying to use the web UI through internal uris.

This issue is being addressed in 3.0 and beyond as we have added service API to get the current requests URI root and are moving all our responses for non-persistent uses to use the requests URIs. This means the icons will have the correct root based on whichever url you are using to access the web UI.

If the URI roots for the icons do in fact match the URI root in the browser, please let me know and we can try to dig a bit deeper.

Adam Archer
Jazz Web UI Developer
0
permanent link
Philippe Preville (36●2●8●8) | answered Jan 21 '10, 3:52 p.m.
There is only one cause for this that I can think of off hand. The work items services return fully qualified urls to the icons using the server's public URI root (this can be configured in the Admin UI). If the public URI of the server is not set, I'm not sure how it computes the root it uses. If the root does not match the one you are actually visiting in your browser, then you will not be authenticated and the requests for the images will fail.

A simple test to see if this is what is going on is to inspect the nodes that should be showing the images and see if the root of their src url matches the root of the url in the browser. If it does not, that is why they are not working.

In 2.x this is a known issue and to solve it you must use the web ui exclusively through the public URI root to avoid issues like this. You will likely see other problems as well if you are trying to use the web UI through internal uris.

This issue is being addressed in 3.0 and beyond as we have added service API to get the current requests URI root and are moving all our responses for non-persistent uses to use the requests URIs. This means the icons will have the correct root based on whichever url you are using to access the web UI.

If the URI roots for the icons do in fact match the URI root in the browser, please let me know and we can try to dig a bit deeper.

Adam Archer
Jazz Web UI Developer


Hi, thank you for your help I set the parameter correctly in the config and everything is now working fine

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.