There's two steps here - finding the issues to remind people about, and then actually telling them.
First step - define a filter. Your requirements are pretty much the filters you need already, probably need more like "unresolved and due date < +1d" and "unresolved and due date < now()"
Second, for each filter, you've got two off-the-shelf options immediately
1. Use a variation on "escalation" - https://confluence.atlassian.com/display/JIRA/Jelly+Escalation
2. "Subscribe" people to the filter - https://confluence.atlassian.com/display/JIRA/Receiving+Search+Results+via+Email
There are other things you can do, but they need plugins/code/thought, so have a look at those two first.
Mmm. The difficulty with saying "there shoud be a button" is it instantly leads to the question "What exactly should the button do?"
You need to add something to define what the interval is (7 days? 14 days?) Then something to define which field you're interested in (created? updated? due?). Then you need to think about reporting - how do I know what is over the deadline or behind it?
How do I get the flexibility of a filter into one button?
The answer is: by a proper definition of a problem and its solution. Patric is right - there should be a simple interface for simple situations. You can still keep flexibility for some dark hour ;)
The most simple case is following:
- an e-mail notification sent to the task assignee
- the task is close to the due date by defined amount of time and still is not resolved
- I need an entry to define the amount of time that will trigger the reminder
- I need a checkbox to mark whether the current task shall have reminder turned on or off
- optionally it would be nice to have a possibility to include/exclude watchers from receiving this reminder
Perhaps it is not one button but it is also not much complicated...
And that's my point - you've just described one way to do it. That's pretty much useless for most of my users, they need something very different. Your "proper definition" is still lacking enough detail to implement, and its also unusable by most users.
It's not a case of defining the problem - that's clear. It's clearly defining a solution because the whole point here is that you need it *flexible* otherwise it's useless for most of the user base.
The "dark hour" you need flexibility for occurs at the north pole, in the winter solstice, and lasts for 99.99% of the day.
Well, to be fair we weren't creating a spec for a developer. If that were the case I would have created mockups with functionality descriptions included, and maybe other details. I don't even know if Atlassian would care if we did create a spec, do their devs or product manager even read this?
Maybe what you're after is more complex and should be part of a different discussion? Not sure, but we are after something simple. I've wasted a lot of time rooting around Atlassian documention trying to get this work and frankly, it's just that, a waste of my time. I've used plenty of other project management platforms and other software where notifications are super simple and easy for users.
Case in point is the documentation, at least what I've found, doesn't explicitly state you can subscribe other individuals to filters. It says you can subscribe groups of people. I don't want to bombard a group of people with reminders about other people's tasks, only the assignee should get one.
And, again, that's the point - you're asking for a fixed system that only works for a handful of people, and hence is pretty much pointless for a generalised system with a wide range of users.
And, yes, Atlassian do read things here, but it's very rare that they pick up any specifications from here (I think I've seen it once, when a user described an improvement that WAS generalised and would work well for a huge swathe of use cases).
It is well worth raising it though - you will get a response of "duplicate/part of", "not going to do becasue...." quite quickly, or, if it stays open, then it's not ruled out. See jira.atlassian.com. But if you do raise it, remember it needs to be at least as flexible as the jelly/subscription stuff. (The escalation and subscriptions don't have a friendly interface, but they work, and there are far more useful things Atlassian have on the to-do list)
Same here - I understand why "a simple interface for a simple case" sounds desirable, but that's the whole point - once you start to try to define "a simple case", you instantly make it pretty much useless to almost all the user-base. As there's a flexible workaround that can be adapted for most cases, there's no point chasing up any "simple case"
Just stumbled upon this thread from Google when searching for JIRA reminders, sorry for the Necro. I created a task to discuss and spec out a project with someone. They're gone next week. I'd like an email on Monday when they return to address this task.
I understand that there are a lot of complex things that could be done, but the simple tool seems like it could be useful for everyone. "Add Reminder" -> "Date & Time" -> "Assignee | Reporter | Watchers"
That's it. At the designated time, an email will be sent to the selected users.
This could be utilized for other situations, such as the deadline, or the supervisor followup. But, not designed around that specific need.
Your escalation link is broken, and the filter subscribe may be what I use, but it is a bit too broad I think. I'll get the "useless helpful" emails every day (or defined interval) and stop looking at them. I think automatic reminders will be ignored, I think periodic reminders will be ignored. But, if there are a very small subset of user desired reminders, there will be few enough, that they're useful and relevant.
In other words, if there are 2 tasks I want to be reminded about Wednesday, one task I want to be reminded on at the end of next month, and one task I want to be reminded on a week from Monday, and I explicitly set these reminders, it won't be filtered into a bin and forgotten because they're action items that the user wanted.
Sounds like you've already made up your mind though, that's fine. =) I disagree.
The escalation link is broken because the conversation is so old.
The interface has also been changed. It's nothing like the so-called "simple" solution I was arguing against of course, because that's simply not useful for most users. It's now a subscription by effectively "cron".
Right, so my current solution is to set the due date to the date I want to be reminded of the task. I.E. although the project is not due next monday, I set the due date to next monday, so then at 5:30am I have a filter subscription. The filter is for any task assigned to me (current user) with a due date between 0 and 1d. With the subscription set to daily at 5:30am.
This will effectively remind me on the day-of the due dates, which will roughly work.
Yes, this is an old conversation, but it is the first result in google when I search for, "jira reminder emails" so it is worth keeping the answer relevant for incoming googlers.
I have to agree with most of the opinions in this thread: why is there not a simple reminder system for tickets with due dates. Nic is arguing for development specifics, but all reminder apps are pretty much the same: add an alert with a relative period from the due date. iCal, et al — it's all the same approach.
Instead, I'm having to manually add reminders to the Apple Reminder app so I am notified on my phone, and that's just silly; I shouldn't have to do this.
Randall hit the nail on the head, "I would be annoyed if I had to set a reminder on each issue I wanted a reminder for." The filters allow you to set generalized reminders for all issues matching the filter criteria. It may even be possible to set multiple filters for different reminder times based on some custom fields. Those of us who use JIRA for tracking several tickets / issues at a time cannot be spending the extra cycles to manage a notification for each ticket that gets created.
Thanks to @Nic for pointing me in the right direction. The solution that worked in one setup, using Jira Cloud, was the following:
Nic: maybe not all do, but clearly there are many Jira customers that use it as a task management system. My company does. And tasks have due dates. And due dates pass by. Which is why reminders are nearly universal across task management applications.
Additionally, the approach used is also very common — from Sales Force to Apple iCalendary to AtTask. I don't think the "we need a spec" arguement, nor the "if it's simple it won't work for most people" arguments are very convincing. There's already a well defined approach to follow: look at Apple iCalendar. It's simple, and very effective. And it works for everyone that wants to set reminders.
Just saying... I agree with others that this is a legitimate request and I'd like to lend my vote for this as well.
The issue with the filter subscription approach (which has been recommended) is that it relies on the assigee to set up reminders for themselves. As a Manager, how can I enforce reminders?Or at least set them up for my team. I don't think I can. Can I?
I still think you've missed the point. Your idea of a reminder is still probably not mine. The approach used is very common, yes, and all I hear about reminders from all sorts of systems is the complaint that a) they don't work or b) they're not flexible enough. In all those cases, reminders quicky become useless because people learn to recognise and ignore them, or they work around them (email rule to bin them. That's what I do with allegedly "helpful" reminders)
The "if it's simple" argument remain valid. Define it. When you say "Look at Apple iCalendar", you're agreeing with me - as the recipient of one of those reminders, I set it up the way I want it. Not to some rule imposed on me.
As for "as a manager, I want to remind my employees", I really do understand it as I am someone who relies on other people to do work. And as an employee, I desperately want you to stop nagging me when I don't need it - it's disruptive and counterproductive. I'm afraid I need to circle back to "we need a spec" - that spec needs to include the way the people get the reminders work, and that means doing it for themselves, and being flexible enough to accomodate that.
Er, Jira already DOES this.
The "handful of customers" refers to the small number of Jira users who want to remove the flexibility provided by Jira because they want it to be "more simple" (more simple = less flexible and hence useful to fewer customers)
Yes, I agree that the issue here is not about whether it does it or not, but about how to make it easy for all users. Which you can't because they all have different needs.
When someone asks for "the simple case", they mean "what works for me". Which is fine for them, but not going to work for the vast majority of other people (on a scale from "it's close" to "it's useless to me")
I'm sorry, I don't mean to discourage you from giving feedback - that's always welcome.
Please do continue with suggestions and comments, they are appreciated.
(I'm not sure what you mean by "plugin community" though, as Answers kind of is that already)
The difficulty with the previous conversation is that it mostly seems to be people asking for a "simple" way to do this, and then not being able to define a simple case that works for more than a tiny handful of users.
This conversation has helped me to understand how hard it can be for a "product owner" - even getting a simple solution that meets all the users needs can be a lot harder than it sounds when you start trying to define it. I've not seen anything that is particularly "wrong" here, just a lot of well-intentioned stuff that falls down when you try to question how it's going to work for anyone else.
The key to this debate is that last phrase "meets ALL users needs" - products rarely do that. The happy medium is meeting most users needs, which are clearly articulated in the thread above. Just because it doesn't work for your particular company's use case(s) doesn't mean that it doesn't fulfill the needs of the majority.
Looks like Atlassian figured out how to do this.
JIRA 7.1: https://confluence.atlassian.com/jiracoreserver071/working-with-search-results-802172637.html (near the bottom)
Implementing what Nic suggested above (option 2) in real action, I think we can
In such way, at that scheduled time, it will send out email to each assignee with the bug list due for him/herself if there is at least one.
This is an old thread but I just (2/2017) started looking for a solution to a similar problem.
The filter and subscribe solution is a kludge at best. We really just want to be able to send a reminder to anyone who gets assigned to a ticket based on upcoming due date, not state changes. With this solution, the assignee either has to subscribe themselves or be part of a subscription group. Just doing "everyone" for an org such as ours would probably grind the system to a halt. We have lots of instances where a number of people will only be assigned a couple times a year. Also the person is going to get the periodic reminder from the date they are assigned till it is due. These sorts of emails have a tendency to get filtered out as noise.
The best solution I can find is a relatively inexpensive plugin which has been around a long time which is probably why Atlassian doesn't have simple reminders as core functionality. Absorbing plugins discourages outside plugin development.
And of course, this plugin only works for Jira Server and I'm working with Jira Cloud. :(
I am also trying to do something like this - send a single reminder based on the due date of a ticket, not based on SLA metric, as a universal rule (affects all users, not just me) and it seems either impossible or needlessly complicated.
...maybe I can create a queue specifically for tickets that are within a certain amount of time of their due date? Everything else I tried, like automation rules, depend on SLA metrics, which I don't want to use. I may be stuck with the filter...
Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...
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