SearchService can only run JQL from database?

[Yan Gao]

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(),
 jqlQuery, PagerFilter.getUnlimitedFilter());
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.

[Nic Brough -Adaptavist-]

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.

[Yan Gao]

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. 

[Nic Brough -Adaptavist-]

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)

[Yan Gao]

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

[Nic Brough -Adaptavist-]

Mmm, it doesn't make sense to do that with JQL, why not check that the field is filled?

[Yan Gao]

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.

[Nic Brough -Adaptavist-]

It's only clauses that are going to be changed by what the user is entering, which instinctively feels like it's the wrong thing to be checking.