We have a JQL workflow validator where a user can write a JQL statement. On the transition, the validator will check if current issue satisfies the JQL statement. if yes, continue; if not, alert.
We use SearchService to run the JQL in our JAVA code. here's a snippet:
It works totally fine except for the following case:
final SearchResults results = searchService.search(ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser(),
List<Issue> issues = results.getIssues();
We have a JQL validator whose JQL statement is"Project Lead is not Empty" for transition from TODO to In Progress. And there's an JIRA issue where the Project Lead is unassigned. So if we move workflow from TODO to In Progress, it should show alert and it does.
However, this time, we add a transition screen that contains the field "Project Lead" for the aboved tranisition and keep the Project Lead unassigned for that issue. When we move from TODO to In Progress, the tranisition screen pops up, and we assign Project Lead to be "admin". Then after hiting the "Start Progress" button, alert shows up and transition cannot be done.
Inside the JAVA code for the validator, we can get the issue and the value for "Project Lead" for that issue is "admin".
CustomFieldManager customFieldManager = ComponentAccessor.getCustomFieldManager();
Collection<CustomField> cf = customFieldManager.getCustomFieldObjectsByName("Project Lead");
Object value = jIssue.getCustomFieldValue(cf.iterator().next());
Our theory is that SearchService only do the JQL query agaist the database. On the transition screen, although we assign "admin" to the "Project Lead", the new value is only in memory/cache, but not in database.
Our question is if there is a way to do JQL query agaist the memory by using SerchService or anything else.
Your instinct is almost right, and it's only a technicality. JQL does not search the database (mostly), it searches the index.
A validator runs after the user has given JIRA some data, but before the change is written into the database or index. So yes, it's searching on your old data.
You won't be able to run the JQL against the input data in a validator. But you should be able to write code that would do JQL for the bits that have not changed in the transition and then build a "what if field X changed to <something>" logic on top of it.
Thanks @Nic Brough [Adaptavist]. That makes sense. We really hope there's way that SearchService can do the JQL and searches the memory.
We thought about the "what if field X changed to <something>" logic, but in our case, because it is a JQL validator, to do that logic, we need to parse/objectify the JQL statment first to do the comparison. That is not really, but we need to reproduce the JQL in our own code base.
JQL really does only run against the index, there's no way it can search for stuff that hasn't been committed to.
The two options I can think of are "JQL result set, modified by working out what the data entry is", or to take a different approach to coding it. On the second one, I do not quite understand what your code is trying to do - could you explain the goal of your code? (Not how it's doing it, but what the user gets out of it)
Here's the screenshot for the JQL validator. the users expect if current issue doesn't satify the JQL statment, it will provent the transition.
for this example, if current issue's assignee is unassigned, show the error message and halt the transition.
Our issue is if users set the assginee in the transition screen (todo -> in progress), it will still show the error message and stop the transition.
Let me know if that doesn't make sense
sorry, that is a bad example. the idea is to run the JQL against the current issue key and provides a PASS/FAIL/Error Message response. The JQL would be really complex, i.e. "status was in ("To Do", "In progress") AND issuetype in (Task, Story) AND Project Lead is not Empty". This is a feature requested by our client and we want to get the advantages from JQL.
A validator to check if a field is filled or if a field value is a certain value is a good idea, but cannot meet all of the requirements.
Thanks @Nic Brough [Adaptavist]. We'll think about that. and we definitely need to redesign the validator.
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
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot