scriptrunners versionMatch functionality searches also for history entries?

[Michael Aglas]

when I use scriptrunners extension for JQL queries in JIRA like:

fixVersion in versionMatch("V00.01*")

I will also get issue that have a fixVersion set to "V00.02.00" for example, if the fixVersion of that issue was set in the past to e.g. "V00.01.00", but was changed afterwards. Does this really make sense? I want to get issues with a particular Version, but I get additional issues that are no longer assigned to this version... so this means to me, I cannot use this feature, because it distorts the result I want to have.

So is this a bug or is it a feature? Is it may be solved with another plugin version?

We are currently using Scriptrunner 5.0.14

[Andy Heinzer · Accepted solution]

Using the versionMatch JQL function from scriptrunner is actually expecting to use a regular expression in regards to how these are being matched.  Please see the documentation on this projectMatch / componentMatch / versionMatch.

In which case, the asterisk * is expected to match the previous identifier repeatedly.   The other thing to note is that the period . will match any character when used in regex.  You have to escape characters like that.  So if you only wanted to find issues with versions that start with "V00.01" then your regex would probably need to look something like this

fixVersion in versionMatch("V00\.01\..*")

Note the escaped \. to match the "." characters, and then the additional .* will match any characters that follow this.  If you're not familiar with using Regex, I recommend using this site, http://gskinner.com/RegExr/   It has been endlessly helpful to me in understanding how my regex is actually be evaluated.

[Michael Aglas]

I get following error using your regex example:

Error in the JQL Query: '\.' is an illegal JQL escape sequence. The valid escape sequences are \', \", \t, \n, \r, \\, '\ ' and \uXXXX.

[Andy Heinzer]

Ah, my apologies.   Try it without those \ characters, and see if the results are more in line with what you are expecting here, such as

fixVersion in versionMatch("V00.01.*")

[Michael Aglas]

Wow, thanks for nothing. Now, I again stuck with my initial complain.

[Andy Heinzer]

Ok, turns out you need to also escape the escaping character.  yay.

Please try this instead.  

fixVersion in versionMatch("V00\\.01\\.")

If this does not work the way you would expect, please let me know specifically what fix versions are returned.   I can't see how this could return an issue with a fixVersion value of V00.02 But I can see how your first query could have returned a value such as V00.012 since in regex the period will match any character unless you escape it.

[Michael Aglas]

Ok, this seems to really do trick. Thank you.

[Naveen Kumar R]

I'm trying to use a regex like-  fixVersion in versionMatch("V_*_2019") in jql but it returns no result but when i modify the regx to- fixVersion in versionMatch("V_*") then i get the output. Why the '*' is not working when used in between the query?

[Andy Heinzer]

Hi Naveen,

The * character in regex isn't exactly the same kind of wildcard as it is in other systems like bash or DOS terminals.  In regex specifically, it's definition is to

Matches 0 or more of the preceding token.

In this case that is an underscore character "_".  I would expect your first query to match only version names such as

V_2019
V___2019
V_______2019
Version_2019

Whereas the second query will match anything that starts with a V and ends with the string _2019, such as

V
V_
V_2019
V___2019
V_______2019
Version_2019
Version 1.0
Version 2.0

The first result and the last two get returned because the use of the asterisk character here is matching zero underscore characters.

Instead trying a JQL query such as

fixVersion in versionMatch("^V_.*_2019")

I think this is more in line with what you want to match. But if I have misunderstood your expectations here, let me know a few example version names you would want to match here and I will see if we can work out a regex that matches appropriately.

I would also recommend the website https://regexr.com/ it's a really good utility for you to test out your regular expressions against a number of sample data in a box so you can see what matches and what doesn't.

Andy

[Naveen Kumar R]

Thank you Andy! My requirement is, I have versions with below values(mentioned just few of them) and I want to fetch the records that have R1_2019 in fixversion
V_AB_R1_2019
V_XY_R1_2019
V_DF_R1_2019
V_XYZW_R1_2019
V_XY_R3_2018
V_DF_R2_2018
...
and so on.

Is there a way to achieve this? 

[Andy Heinzer]

I would try either

fixVersion in versionMatch("^V_.*_R1_2019")

or

fixVersion in versionMatch(".*_R1_2019")

The first will only match those that start with a "V_", while the latter option should match any string that ends in "_R1_2019".

[Naveen Kumar R]

Thank you Andy for your help! The second option worked for me.

[Abhay Patil]

@Andy Heinzer -

fixversion in versionMatch ("20\\.9\\.") matches ID-R20.9.1 which is expected.

Just adding * at the end should not make any difference, but

fixversion in versionMatch ("20\\.9\\.*")  matches ID-R20.9 - in spite of having \\. after 9, which doesn't exist in  ID-R20.9 .

Isn't this a bug?

[Andy Heinzer]

@Abhay Patil I don't believe this is a bug.  The * character in regex is expected to match 0 or more of the preceding token. In your case, it matched 0 of that last token. Instead I think you want to use the + character, which has to match 1 or more of the preceding token.  

I also like to plug the site https://regexr.com/ as my source for testing regex.  You can see this for yourself under the Regex reference > Quantifiers & Alternation on that page.  This has always been a helpful resource for me to test out my expressions before deploying them.

[Abhay Patil]

Thanks a bunch @Andy Heinzer - I missed the nicety of * that includes matching of zero occurrences as well.