changeset link behavior changed in RTC 3?
We just updated from RTC 2.0.0.2 to RTC 3.0.1.2. We use the auto-comment when adding/removing link option from the "Restrict Associating To Closed Work Items". In Eclipse with the RTC 2 client, when I clicked on the changeset link in the comment, it opens the changeset in the Change Explorer. But now in RTC 3 eclipse client, it is launching the a browser in eclipse to view the changeset in the web client.
Is this intended behavior, or a bug? Seems like it may be a bug to me...why would anyone want to open the changeset in the web client when you click its link in the Eclipse client? Is there a setting somewhere that will change this behavior and get the changeset to open in the Change Explorer again? |
9 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Apr 06 '12, 8:20 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I just tried this in my RTC 4.0-RC1 eclipse client, and the changeset opens in the Change Explorer, as expected. So unfortunately I was not able to reproduce the behavior you describe.
Cheers, Geoff We just updated from RTC 2.0.0.2 to RTC 3.0.1.2. We use the auto-comment when adding/removing link option from the "Restrict Associating To Closed Work Items". In Eclipse with the RTC 2 client, when I clicked on the changeset link in the comment, it opens the changeset in the Change Explorer. But now in RTC 3 eclipse client, it is launching the a browser in eclipse to view the changeset in the web client. |
Did you change the name of the server or the ports? The only reason I can see that it would do that is if it didn't find the repository connection in Eclipse. It will open the change set link in a web browser if it doesn't find a suitable connection. A different server name would cause this to happen.
|
|
No, we didn't change server names at all.
I did verify tthat the links created with the RTC 2 client before the upgrade are the ones trying to launch the web view. New links created after the upgrade are opening in the Change Explorer as expected. Did you change the name of the server or the ports? The only reason I can see that it would do that is if it didn't find the repository connection in Eclipse. It will open the change set link in a web browser if it doesn't find a suitable connection. A different server name would cause this to happen. |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Apr 09 '12, 9:30 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Just for interest's sake, hover over one of the old links in the WebUI, select the "copy link location" operation, and save the URL. Then do the same over one of the new links, and see how they differ.
Cheers, Geoff No, we didn't change server names at all. Did you change the name of the server or the ports? The only reason I can see that it would do that is if it didn't find the repository connection in Eclipse. It will open the change set link in a web browser if it doesn't find a suitable connection. A different server name would cause this to happen. |
|
The two URLs are exactly the same except for the UUID at the end. The hover popup's both appear to have the same content on the web as well.
The hover contents are different in Eclipse though. The old one created with RTC 2 only has the URL as the contents of the popup box when I mouse over the link. When I mouse-over the new link, it does show the creator, date, comment, etc.. There is one slight difference with the URL for the old comment in the eclipse client -- it has a ":443" for the port. I wouldn't think that would matter though since the other URL's should be using that default https port as well. Just for interest's sake, hover over one of the old links in the WebUI, select the "copy link location" operation, and save the URL. Then do the same over one of the new links, and see how they differ. No, we didn't change server names at all. Did you change the name of the server or the ports? The only reason I can see that it would do that is if it didn't find the repository connection in Eclipse. It will open the change set link in a web browser if it doesn't find a suitable connection. A different server name would cause this to happen. |
|
The default port is 9443, not 443. Or do you mean the old URL doesn't have the port specified?
|
|
We do run our server on 443. (always have) So I meant the default ssl port as a general statement, not as the default jazz server https port :)
Neither of the links in the web client specify a port -- both are exactly the same except for the UUID. (e.g. https://domain.com/jazz/resource/itemOid/com.ibm.team.scm.ChangeSet/_RJ6vIVjpEeGZyeDiShe67g) All I was saying was I noticed the old comment link in the Eclipse client does show a :443. (e.g. https://domain.com:443/jazz/resource/itemOid/com.ibm.team.scm.ChangeSet/_RJ6vIVjpEeGZyeDiShe67g) The default port is 9443, not 443. Or do you mean the old URL doesn't have the port specified? |
|
I'm not sure if the port existing in the old link is causing the problem but I think you should open a work item (filed against Source Control for now).
|
Note to readers of this forum post. This issue can be tracked in the Jazz work item here:
https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/208743 |
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.