Escalation service not fully respecting filter
*This issue has moved*
This issue has been moved permanently to Adaptavist's Product Support JIRA instance.
All existing users of this instance should have the same username on our Product Support instance. However, you will very likely need to click on the
Can't access your account link in order to reset to a new password.
we had set several escalation services, but particular one is not working as expected. We had set filter:
the inactiveUsers() is our custom JQL function (used in different escalations and working just fine)
The status = resolved part of JQL above is crucial. After tomorrows upgrade (to 3.1.3) users are reporting that they're receiving escalations on open issues. Also when I test the very same JQL as above with addition ...AND key=affectedissuekey the query has no results.
How it is possible for escalation service to do actions on issues, that are even not result of such filter?
Please help. Thanks
is there any progress or any information to share? I'm really interested if I somewhat misused the functionality or if there is some issue.
I have tested with user service is configured under with the same result.
Additionally I have done some more research and found out that the issues escalations are sent are part of different escalation service (and filter) but the additional code executed is from the first one...an that's terribly wrong!!
escalation1 - filter1 and additional code1 sending email notifications
escalation2 - filter2 and additional code2 sending email notifications
CRON'd at the same time.
RESULT: additional code1 is user for filter2 of service2
Could you please check i there isn't some issue in code that could result in this behavior?
As of now I will change the CRON expression not to trigger those services at the same time.
Thanks for your help.
PS: yes, clause is redundant, but irrelevant for this case.
> Also when I test the very same JQL as above with addition ...AND key=affectedissuekey the query has no results.
Make sure you run it as the same user you have configured the service to run as - you can use Built-In Scripts -> Switch User to do that.
> How it is possible for escalation service to do actions on issues, that are even not result of such filter
It's not, is the short answer.
> and status = resolved and status != Closed
The second clause seems redundant here.