I have a field called "Customer / Partner" that uses the database values plugin to get a field. I want to put a validator in that checks to see if this field is filled out during "Create Issue" transition. I am using the simple script validator:
cfValues['Customer / Partner']
And upon creating an issue it works! However when I go to clone an issue it will return true even if the value of the above field is None?!? Strange as I would assume the conditions for checking against validator for create issue and clone issue would be the same.
Does anyone know how to print the value the field is giving with a simple script validator? Can I do it somehow in the Error Message I am returning? Or does anyone know the code difference between creating an issue and cloning an issue.
I can do the following and this fixed it! Here is my code. So since Database values pulls the data from an external database it must use a default value ATTO0A200002 for the field. So this fixed it:
cfValues['Customer / Partner'] == null || cfValues['Customer / Partner'] == 'ATTO0A200002'
So on doing an issue create the value is "null" as it is checking with the field and on doing an issue clone it is straight pulling from the database. So that covers both!
Thanks again Kristian for all your help in resolving this one!
Looking at your Youtube video and it looks as if the Customer field is a single select list field. To validate that a single select list field matches a value using ScriptRunner then you should use a syntax similar to below. This syntax could be applied to a Simple Scripted Validator to display an error to the user if this value is different when the create transition is executed.
cfValues['Customer']?.value == 'Partner'
I hope this helps.
Thanks for the reply! I am not looking for a particular value. I am looking to see if it has any value at all. The field is called 'Customer / Partner' so essentially I am looking for
cfValues['Customer / Partner'] != EMPTY OR I could try:
cfValues['Customer / Partner']?.value != EMPTY
So by your example cfValues['Customer'] should be enough to see if that holds a value (If I had a field called Customer, it is actually called Customer / Partner). Also as you can see from the video, on create issue it works. Then when I try to clone it fails. I really do believe this is a bug in script runner. I worked with Atlassian and they said it is on the script runner side.
I tried the conditions:
cfValues['Customer / Partner']?.value == EMPTY
cfValues['Customer / Partner']?.value == ''
cfValues['Customer / Partner']?.value
None of which works. I think it may be the way database values plugin is returning the value, as another text field works. Still weird that it works on create and not on clone though...
As your issue is with a field provided by the third party Database Values plugin then you will need to contact the Vendor of this plugin via a support request to see how they recommend to access the values for the field.
The examples above show how you can validate that the select list has a specific value or is not not null using the code below.
cfValues['Customer']?.value != null
If the Database Values plugin is storing the values in a different format to a standard JIRA Select list field then you will need to contact the vendor to ask how you should access the values.
Thanks Kristian, I assume you mean me (never been called Randy before , Rob, Robert, Roberto, Bob, but never Randy)
null as well no luck. I agree that it may have something to do with the DB values plugin, and I am not blaming scriptrunner or claiming there is a bug in it, heck I could not live without it! I use SR all the time. I just find it strange that clone would be different from create. Like I said all solutions work great on create. They just fail on clone, and I was hoping someone could give some insight, on where to debug. I know that clone won't clone the fields I listed above, but removing the validator does clone the fields correctly, just does not detect them.
I was really hoping someone could tell me a way I could see the value cfValues is returning, not just compare it, as that would give me insight. Possible in the error code reference cfValues or something?
Anyhow thanks again for your responses!
Apologies for calling you the wrong name, I got my names muddled up with another message that i was sending.
As for checking the values returned by cfvalues, you may bale to do this by including some log.debug statements in your condition otherwise you may find the documentation here helpful which talks about the structures used by cfvalues.
Thanks, and no worries about the wrong name I have been called worse
log.debug is what I believe I am looking for! Actually I had to use log.error as I believe I am ignoring INFO.
Weird but when I create the issue I put a value in there (AEPHJA30000M). Ii blocks it. Check
atlassian-jira.log:2016-03-30 16:25:35,356 http-bio-8443-exec-25 ERROR rnadon 985x101354x1 d5lenn 10.11.206.35 /secure/QuickCreateIssue.jspa [canned.jira.utils.ConditionUtils] RNADON ZZTEST: AEPHJA30000M DONE ZZTEST
I remove the value (null) and it works again
atlassian-jira.log:2016-03-30 16:25:57,147 http-bio-8443-exec-5 ERROR rnadon 985x101356x1 d5lenn 10.11.206.35 /secure/QuickCreateIssue.jspa [canned.jira.utils.ConditionUtils] RNADON ZZTEST: null DONE ZZTEST
When I go to clone even though there is no value in there it is finding the original value I placed in there?!?
atlassian-jira.log:2016-03-30 16:26:16,280 http-bio-8443-exec-5 ERROR rnadon 986x101362x1 d5lenn 10.11.206.35 /secure/CloneIssueDetails.jspa [canned.jira.utils.ConditionUtils] RNADON ZZTEST: ATTO0A200002 DONE ZZTEST
That almost sounds like a bug in JIRA clone as it should take the current value not the original one!
Actually I see now those are two different values. What it is in the database it store it in a unique manner: In the table customfieldvalue
Every data is listed as, for that field, STRINGVALUE ATTO0A200002
And that is where it is messing up. Wow what a tricky one! OK it is the DB value plug in the way it store in the database.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs