"Issue not found" when hovering over task

Hi all,

this is a forum post to further inspect TW-8972. Maxim, you wanted to know how the HTTP traffic looks at that point.
Attached, please find a pcap file I made with Wireshark. According to this, there's a POST request made to
/issueDetailsPopup.html?issueId=
without any parameters. The strange thing is that when I look at the traffic in Firebug, it displays the POST URL as
/issueDetailsPopup.html?issueId=#15&providerId=redmine1
This made me take another capture with Firefox but there's no difference in the parameters present in the actual HTTP traffic, so I guess we may be on to something.

All the best
Marcus



Attachment(s):
issue_not_found_firefox.pcap.zip
issue_not_found.pcap.zip
5 comments
Comment actions Permalink

Hi Marcus,

Thanks for the snapshots!

> The strange thing is that when I look at the traffic in Firebug, it displays the POST URL as

/issueDetailsPopup.html?issueId=#15&providerId=redmine1
Please note the "#" symbol in the URL. That is the reason why the parameters are not received in the controller.

I must admin there is lack of validation and/or documentation on our side.
Please take a look at extractId() method. I think it is the key to resolution.


---
Maxim

0
Comment actions Permalink

Hi Maxim,

no problem. I was under the impression that extractId implementation from AbstractIssueProvider using regular expressions was sufficient, as it successfully extracts the issue id to generate the correct URL (i.e. /issues/123 instead of /issues/#123).

All the best
Marcus

0
Comment actions Permalink

Hi again,

in the interest of understanding wherein the problem actually lies, I will recapitulate what's going on:

  • My IssueProvider inherits from AbstractIssueProvider, which allows for regular expressions to extract the issue id
  • As it is the syntax Redmine uses, my tickets are in the format #12
  • Thus, the regular expression is #(\d+)
  • The ticket URL is correctly generated as /issues/12
  • The issue popup URL is apparently generated from the whole regular expression (compared to the first matching group) as /issueDetailsPopup.html?issueId=#12&providerId=redmine1 - including the prefix.


Now my guess is that the code which generates the popup URL would just need to URL-encode the issue id so it reads issueId=%2312 and the IssueFetcher will handle the rest...


All the best
Marcus
0
Comment actions Permalink

Hi Marcus,

You're guessing right. There are two ids for an issue: an external one in the syntax that is convenient for users, and internal one. In your case I think "#(\d+)" is the best for external, and just "\d+" is best for internal.
Now if you don't override a "extractId" method, both ids will be the same. It's hard to say from scratch why some of the URLs are generated correctly, I would propose to add "extractId" method:

  protected String extractId(@NotNull String match) {
    Matcher matcher = myPattern.matcher(match);
    matcher.find();
    if (matcher.groupCount() >= 1) {
      return matcher.group(1);
    } else {
      return super.extractId(match);
    }
  }



If anything goes wrong after this, I will have to analyze the source.

---
Maxim
0
Comment actions Permalink

Hi Maxim,

thank you for the help and insight. Indeed, with the added extractId method you proposed, everything is working as it should now!
I have updated the source code and compiled versions of my plugins at https://github.com/milgner/TeamCityRedmine/ and https://github.com/milgner/TeamCityGithub/ accordingly.

All the best
Marcus

0

Please sign in to leave a comment.