date based reminder notifications
Asked by Drew McManus:

I'm looking for a solution to address a scenario we encounter where a dev moves an issue into Test but QA does not have the bandwidth to address right away.   

As the QA tester, I need a way to get a notification to help prevent the issue from falling between the cracks.   

We routinely use due dates for issues so I don't want to use that as the trigger but are there other options available that use date based fields or a way to generate a notification if an issue hasn't been looked at by the QA tester or number of days since the card was moved or last commented?  

Another potential angle we've considered is creating a filter view that only shows issues that haven't had any movement in {#} days.  

I'm open to other solutions if anyone has ideas.


Answers:
author: Victor - Modus Create
body: Hi [@Drew McManus](/t5/user/viewprofilepage/user-id/4404667) ,

From what I understood of your request, it seems that you would find an alternative for this using Notification Assistant for Jira Cloud:

- [https://marketplace.atlassian.com/apps/1211069/notification-assistant-for-jira-email?hosting=cloud\&tab=overview](https://marketplace.atlassian.com/apps/1211069/notification-assistant-for-jira-email?hosting=cloud&tab=overview)

The app allows you to set many different triggers that could help you with the task at hand.

Hope it helps.  
Cheers,  
Victor \| Modus Create


author: Trudy Claspill
body: Hello [@Drew McManus](/t5/user/viewprofilepage/user-id/4404667)

If you can develop a filter to find the issues you want, you can subscribe to the filter and receive its output periodically in an email.

The trick is you have to be able to identify which issues are of interest.
> if an issue hasn't been looked at by the QA tester or number of days since the card was moved or last commented?

Jira doesn't record the number of days since an issue changed status, nor the number of days since the last comment was made. You could create automation rules that would update a custom date field (that you make) to record the date each time an issue changes its status, and/or has a comment entered, and then that date field can be part of the issue selection process. You could then create a filter that selects issues based on:

"Your custom date field" =\< startOfDay(-###)

...where -### is the number of days you want as your limit. You would, of course, have additional criteria in the filter to further limit the issue returned, such as **status=Test**

Do you have any experience with Automation Rules?

<https://support.atlassian.com/cloud-automation/docs/jira-cloud-automation/>

comments: author: Drew McManus
body: Thanks Trudy, I don't have a great deal of experience with automation rules, no. That's one of our pain points using Jira is the VERY high learning curve to get something more than a kanban board with cards that have customizable fields.  

Team members change the assignee for issues between devs and testers as work progresses so I wonder if an automation that uses the number of days when the assignee was changed would work.   

I see there's an "When:Issue Assigned" option but I don't know where to go for the If conditions to set the number of days to trigger the notification. I don't see any date based conditions as options.


author: Trudy Claspill
body: Hello Drew.

Jira does not record "days since" something changed in specific fields. The date that things changed is recorded in the issue History entries, but there is no simple way to get a specific history entry or history entries related to specific things.

There is a special JQL operator called CHANGED that can be used with a limited number of field, including the Assignee and Status fields.

<https://support.atlassian.com/jira-software-cloud/docs/jql-operators/#CHANGED>

You could use a filter like:

status=Test and status CHANGED TO "Test" BEFORE startOfDay(-###)

That would give you the issues currently in Test that were also changed to Test some number of days ago. But that alone doesn't tell you whether or not the Assignee has made any changes to the issue since then.

What other conditions/activity in the issue would help you determine if something had been done by the tester since the issue was transitioned to Test?

What would you want to do with the output? Do you want one list sent to 1..n people? Do you want a list sent to each Assignee with just the issues assigned to them?


author: Drew McManus
body: Roger that and this all helps. In our process, assignees are handled by the respective team members, here's a typical scenario:

* Issue in Dev is moved to Test by Developer User
* Developer User changes Assignee to QA User
* If QA User discovers something the Developer User needs to address, they change the Assignee back to the Developer User and add all testing notes as a comment.
* This continues until the Issue is ready to move to the next stage.

Usually, QA Users are able to jump on testing the same day an issue is Assigned to them so the problem to solve here is to help QA Users remember the ball is in their court during periods where testing tasks exceed bandwidth. Having Jira send a notification when an issue has no activity for X number of days would make sure nothing falls between the cracks.


author: Trudy Claspill
body: Hm, okay, how about this.

Create a filter that selects the issues based on status being Test, Assignee being a particular Tester, and the Updated timestamp being "old".

You can create a generic filter like this:

project = *insert your project here* and status = Test and Assignee = currentUser() and updated =\< startOfDay(-###)

Share this filter with your QA team user group or with the project as a whole.

Have each Tester subscribe to the filter themselves.

Each one will receive the list of issues in Test and assigned to just them where there have been no updates (no comments, no status changes, no changes to any of the fields) in ### days.

If some one user (i.e. the manager of the testers) wanted to receive a list of all the issues then you would want a separate filter.

If your testers all belong to a user group you could use:

project = *insert your project here* and status = Test and Assignee in membersOf("*insert user group* *name here"*) and updated =\< startOfDay(-###)

Otherwise you would have to list out the individual Testers:

project = *insert your project here* and status = Test and Assignee in (tester1, tester2, tester3) and updated =\< startOfDay(-###)


author: Drew McManus
body: I appreciate all the assistance here Trudy. We're still not getting what we're after and it just adds to the level of frustration we increasingly run into with Jira. Learning curves are way too high and the overreliance on having to write scripts only exacerbates those feelings.


author: Trudy Claspill
body: Hello [@Drew McManus](/t5/user/viewprofilepage/user-id/4404667)

I'm happy to continue to try to help you achieve your goal. To do that I'll need more information.

Can you provide information on what you have implemented, what you hope/expect to get, and what you are actually getting?

Are the messages not being sent?

Do the messages not contain the information you expect?

If issues are missing can you provide the details for those issues from the fields that are being used in the filter?

If issues are included that you think should not be, can you provide the details for those issues from the fields that are being used in the filter?


Tags: cloud

jira-cloud