Should custom workflow status change trigger filter synchronizer to reevaluate the issue?

[Laura Savičienė]

Hi,

I have the following filter synchronizer configured in the structure:

Filter (JQL query)

JQL query: type = projektas and "Padalinys/sritis (issue)"~PPD and project != DP300 and "Portfelio skyrius (issue)"~B and status != Nutrauktas

Add matching issues, as sub-issues of DP300-2

Move matching issues from other locations in the structure under DP300-2

Remove non-matching issues (only from under DP300-2)

I would expect that when I change the status of some "projektas" type issue under DP300-2 to "Nutrauktas", the filter should reevaluate it, and remove it from structure.

But when I did that (the following is copy-paste from Activity stream):

Laura Savičienė changed the status to Nutrauktas on HX207-1 - <...> with a resolution of 'Done'

Projektas penktadienis at 9:54

nothing happened in the structure, until I manually resynched the synchronizer in question three days later (also copy-paste from activity stream):

Synchronizer "Filter (JQL query)" on behalf of Laura Savičienė removed HX207-1 and 7 sub-issues from DP300 - PPD portfelis

from DP300-1 / DP300-2

9 minutes ago

So my question is - is this some misconfiguration from my part, and I should configure the synchronizer differently, or this is the expected behavior?

In other structures I have observed that filter synchronizers reevaluate issues when they are "resolved" in the standard Jira workflow, so maybe in this case the reason is that this "Nutrauktas" state is from custom workflow, and is somehow processed differently?

[Eugene Sokhransky _ALM Works_ · Accepted solution]

Hello Laura,

It looks like HX207-1 also had some sub-issues, which at the moment, when you changed the status of the parent were probably still passing the filter. The synchronizer will not remove an issue, if it doesn't pass the filter, but does have sub-issues, which are still valid. The name of the status does affect anything as long as the JQL that you use works correctly.

Does this explain this behaviour?

Regards,

Eugene (ALM Works)

[Laura Savičienė]

Hello Eugene,

Thank You for the answer. It does explain a bit, but not entirely.

You see, those sub-issues don't pass the filter and never did... This is related to another question which was bothering me for a while. I posted it separately (https://answers.atlassian.com/questions/14193413) and, having the answer, will get back to this one, to figure out how to achieve the behavior I want.

Regards,

Laura

[Eugene Sokhransky _ALM Works_]

Hi Laura, I've just answered your other question. Perhaps, if you can provide more details on the configuration, we can try to suggest some ideas.

[Eugene Sokhransky _ALM Works_]

Hi Laura, sorry for the delayed reply. It looks like this configuration is a bit too complicated for the general discussion here at Atlassian Answers. Could you please create a request in our JIRA and we'll continue there? Here is the link: http://almworks.com/structure/support-request

[Laura Savičienė]

Hi Eugene, I have created the support request, as You suggested https://jira.almworks.com/browse/HJ-2210 , and I'll delete (or at least try to :)) my previous comment here. Thanks, Laura

[Laura Savičienė]

Another observation related to that custom workflow state. I have another structure, which contains issue with status "Nutrauktas". I create and resync the following synchronizer: Filter (JQL query) JQL query: status != Nutrauktas Remove non-matching issues and it doesn't remove the issue. Maybe, the filter synchronizer is not supposed to work like that - removing, but not adding, but another similar synchronizer: Filter (JQL query) JQL query: project != BX000 Remove non-matching issues works like expected and removes all issues from anywhere in the structure if they belong to project BX000. Am I missing something really really simple here? What should I do to remove issues according to this status?