shortname in change event eamils, dashboard query links
Hi All,
I've searched the forums and work items and wasn't able to identify the cause of this issue. URL's to work items in change event notification emails use the shortname for our server rather than the longname. Also on the dashboard links to work items take this form:
https://shortname.host.com/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/3280
When this is redirected we end up here:
https://shortname/jazz/web/projects/projectname#action=com.ibm.team.workitem.viewWorkItem&id=3280
The problem is that shortname isn't resolvable by everyone without the correct DNS suffix config and we also get prompts for a second login as well.
Any help in identifying where this could be coming from would be appreciated. We are running in WAS...
Dan.
I've searched the forums and work items and wasn't able to identify the cause of this issue. URL's to work items in change event notification emails use the shortname for our server rather than the longname. Also on the dashboard links to work items take this form:
https://shortname.host.com/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/3280
When this is redirected we end up here:
https://shortname/jazz/web/projects/projectname#action=com.ibm.team.workitem.viewWorkItem&id=3280
The problem is that shortname isn't resolvable by everyone without the correct DNS suffix config and we also get prompts for a second login as well.
Any help in identifying where this could be coming from would be appreciated. We are running in WAS...
Dan.
4 answers
I've searched the forums and work items and wasn't able to identify
the cause of this issue. URL's to work items in change event
notification emails use the shortname for our server rather than the
longname. Also on the dashboard links to work items take this form:
https://shortname.host.com/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/3280
When this is redirected we end up here:
https://shortname/jazz/web/projects/projectname#action=com.ibm.team.workitem.viewWorkItem&id=3280
The problem is that shortname isn't resolvable by everyone without the
correct DNS suffix config and we also get prompts for a second login
as well.
Any help in identifying where this could be coming from would be
appreciated. We are running in WAS...
In the Admin Web UI, you could configure the Public Root to the fully
qualified host name. This parameter is used when we redirect.
--
Regards,
Patrick
Jazz Work Item Team
Thank you for pointing this out. Hectic day yesterday with bringing up a newly migrated server for a bunch of users. I had looked through the server properties but missed this.
Unfortunately this appears to have broken all navigation to work items from within the web UI - even when I reset it to its default value of blank. It appears that the correct URL is being redirected to when clicking on a resoruce link - regardless of what I've set at the public URI root is set to. This error comes up for all attempts to view/edit a work item, even from queries, etc:
So now I've broken my system entirely :(
Unfortunately this appears to have broken all navigation to work items from within the web UI - even when I reset it to its default value of blank. It appears that the correct URL is being redirected to when clicking on a resoruce link - regardless of what I've set at the public URI root is set to. This error comes up for all attempts to view/edit a work item, even from queries, etc:
Error!
Error fetching or storing Work Item 1660 | Details: Error opening work item. assertion failed:
So now I've broken my system entirely :(
Ok - it was operator error in terms of the specification of the public URI root. Once I specified it fully (https://mydomain.com/jazz/ - we're running on 443) my errors go away.
There is some possibility that we never validated the web UI when looking at work items post migration and therefore it was always like this.
I did find that the /etc/hosts file on the machine listed the shortname and then the longname rather than vice-versa. Could this some how have played a role?
There is some possibility that we never validated the web UI when looking at work items post migration and therefore it was always like this.
I did find that the /etc/hosts file on the machine listed the shortname and then the longname rather than vice-versa. Could this some how have played a role?