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...
I'll chime in too... +1 for having reminders. If there's a due date field, there should be a concept of a reminder. It's silly that there is even debate about this.
Teamwork.com and basecamp send emails by default; it's strange Jira doesn't even have the capacity to set up a simple reminder.
Example: outlook and calendar events. User's can set a default reminder that's used every time a new event is created, but they have the option to change that reminder.
It does have reminders. It just needs you to define ones that work for you. Have another read of the conversations above and you'll see why it doesn't do "one size fits all" (because it's broadly useless), and your various options for getting them working well for you.
I read them before posting. It's for sure one size fits many.
I'd be willing to bet that the majority of people who have went through the trouble of creating a custom filter and subscribing to it, have one equivalent to this:
assignee = currentUser() AND status != Done AND duedate < startOfDay(2d) ORDER BY duedate ASC
It took me 20 minutes to do something that most competing applications/services do by default.
But start of day (2d) is useless to me in some projects. One size fails miserably to work for everyone. Even my PM and Consultants need different reminders to me, and we're all working on the same things in the same projects.
If you had read the postings properly, you'd have seen the one that says "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." That remains true.
If software features were limited to features that fit EVERYONE, there would never be anything created.
Global/Site Setting: [Enable/disable] [notification type] sent [days] before [datetype]
User setting: Based on global setting
Jira Task setting: Based on assigned User Setting
My setting would be: [Enable] [Email] sent [2 days] before [due date]
All other situations could be covered with existing features. People who would get annoyed at reminders, could disable theirs.
Nic, you appear to be the only one really against this, maybe 2 others who are not as passionate about you. And the other 10 or 15 people who took the time to comment here, all want this.
One Stackoverflow page "Jira issue reminder" has been viewed 8,484 times
This is not something that "few" people want.
I think you are completely missing the point. A tiny handful of people want something that saves them having to think about setting up a system that already does what they want if they put a bit of thought into it. There's no need for it from the majority of people (there's a lot more than 8,484 people who have not looked for it. Heck, I worked at a place with 120,000 active users who didn't want it). There are more important and useful things Atlassian could be adding than a default that most people won't find useful.
I am not missing the point you are trying to make. I understand you don't want it. And I understand many people would not want it. However, you are assuming most people don't want the feature. Did you actually ask all 120,000 people "do you want this feature?" Did you get a response of "no?" I highly doubt there is even a single organization that has 120,000 active Jira users. Microsoft (One of the largest software companies) has 124,000 employees (2016). I doubt they use Jira, and even if they did, I doubt 97% of their employees would be coders/supervisors/management that would use Jira.
But for argument's sake, lets assume what you are saying is true. With the solution I am suggesting, it would take 1 person 1 minute to disable notifications for all 120,000 users, by default.
The reason I point to Stackoverflow is that page proves there is some level of interest in the feature. More than just a handful of people. Thousands of people sought out a solution.
Just because you would not use the feature, it doesn't mean it would be extremely valuable to other users. Why fight so hard for something that you don't want? If you don't want it, don't use it.
We've been told we have one of the largest single instances of JIRA in the world. We have infrequent users that don't typically have JIRA open in their browser and need an email reminder. Our admins are too busy trying to resolve other issues with JIRA and confluence and don't have time to run reports and email out reminders.
Why would I ask? There's thousands of things far more useful to them, and most of them have happily set up the reminders they need for themselves, most of which are far more useful than the arbitrary fixed reminder that suits a tiny handful of them (or, for the infrequent users, asked someone to set it up for them)
I don't need to point at a few users who have actively looked, especially as most of them are perfectly happy with "It does do it, I just have to set it up, instead of hope that someone has defaulted one that happens to suit me".
>I highly doubt there is even a single organization that has 120,000 active Jira users
I can point at 5 my squad has worked with over the last 3 years.
But that's not my point. I'm not sure what you're reading, but you've not grasped the stuff above. I can't explain it again.
Lets assume half of that 120,000 organization wants to have at least 1 reminder email that fits within my example. Let's also assume, like me, it took 10 minutes to hunt for a solution on how to create the reminder, and implement the solution. Lets then assume these folks get paid $60 an hour. That's a total cost of $600,000 ((120,000/2) * 10 min * ($60/60)) to set up a single common notification.
Just because there is an existing complex way of setting up simple or complex notification doesn't mean a simple additional way would be high valuable to many people.
Why would you ask if they want notifications? Because you really shouldn't assume what people want.
You can't say many people don't want it. That is an invalid argument. You can't talk for anyone other than yourself.
I think your numbers are poor assumptions. A more reasonable assumption is that 0.02% want a reminder email like yours, and maybe 1% want email reminders at all, and in my experience, 95% want Jira to stop (or have learned to ignore it)
>Why would you ask if they want notifications?
What about the other hundred and eleventy twelve things people want? Especially the other things they want more? I don't have time to do any fixing if I have to go around asking people closed questions. As an admin, I ask open ones - not "do you want X", but "what kind of things do you want?". That gives you a list, and "arbitrarily preset notifications that are useless for most of us" is never on it.
That said, there is a "reminder service" suggestion open with Atlassian and they have not closed it "won't fix". It's had a grand total of 30 votes since 2003. Compare that with "reduce email chattiness", of a similar age and nearly 1,300 votes (the list is 4,500 items long, I don't have time to ask users 4,500 questions)
Just quit arguing with this guy. He's not going to change his mind if he just keeps making the same assertions over and over that it's a useless feature. If I was atlassian, I'd be horrified there was some customer running around my message board telling people their feedback was something no one wanted.
Turning off my notifications. I can't believe this is still just you going around and around with people about how no one wants what you don't want; it's been almost 4 years since you scolded me off this subject and I'm still getting pop up about your posts.
I'm assuming that was aimed at me. It's not a case of "I don't want", it's a case of "there is no evidence that the majority wants this". I'll take the assertions point, but I would point out that my assertions are backed with evidence and experience. Have a look at the queue of issues open with Atlassian, including all the ones saying "less email please", if nothing else.
It's a lie to say I'm "telling people their feedback was something no-one wanted". I'm asking that feedback is considered and useful. Show evidence, don't just assume that because you want something, everyone else does. By all means, ask, especially if things might have changed, but instead of just yelling "I want", and inventing numbers, read and understand the existing arguments against it, and counter them.
The evidence here is not "should not do this", but that it's probably never going to become worth doing, given the other things people do want a lot more, and the effort involved given that people want less email, more modern ways of collaborating and reporting, and can set it up if they need it.
I had not idea I could vote. Where can I vote for this feature?
I too am surprised JIRA doesn't have a simple reminder system. And I agree that the recommended way to solve this problem by using saved search notification is incredibly complicated, including the fact that it's on a user-by-user basis only (which simply doesn't scale as each user has to manually add this for it to work organization-wide). It's not clear to me why there's a due date attribute on a ticket without this basic function.
I'm frankly surprised how flippant Atlassian has been about this issue. Years earlier, it was argued that this function doesn't have a straight-forward implementation, which I believe is demonstrably false: nearly all apps that have due dates have almost the exact same reminder function outline in this thread. I don't see any ambiguity here. And when this was pointed out, now there's a secondary argument: well, we simply have better things to built. I'm sure that's true — and I think it's easy to say that most JIRA users are also building software products — so we're familiar with how decisions like this are made. But I would ask for a respectful tone as clearly there is a desire (however small) for having a robust reminder function in JIRA. In fact, I for one would like to vote for this.
Thank you for listening.
This whole topic is hilarious. It's like most people have never used jira.
How it usually goes:
A: How can I do x?
B: You can't, you need to either script it yourself or buy this expensive plugin.
A: Ah, ok.
How this ticket is going:
A: How can I do x?
B: Like this.
A: I don't like the way I'm doing that, it should be easier, Atlassian should spend time accommodating my needs.
OK, so this thread is 5 years old and crazy long. I'm also looking for something that will email any assignee of a ticket that belongs to a certain project any time they have a Past Due ticket.
Is there's a step-by-step answer buried in this thread somewhere that I can follow?
If I have a ticket that was due yesterday, I want to get an email reminding me to close it or change the due date. And I want to basically force this on my team without them having to manually go subscribe to something.
Can that be done? Maybe I missed it in all the arguing in this thread but I finally just scrolled to the end...
+1 on what Ed said. What seems like a basic function is not supported by Jira and a number of people agree with Atlassian's position on this. There are 1 or more plug-ins available so people obviously want the functionality. They would just rather not have to pay extra for what seems like a basic function. Issue Reminders was the one I was looking at.
assignee = currentUser() AND resolution is empty AND duedate < startOfDay()
and then subscribe your team's jira group to the subscription. If you set it not to notify when the filter results are empty, it will only notify each person in the group who has one or more unresolved issues that are overdue. I just tried it and it worked as described.
@Ed Hayes III, yes, they are personal messages, not a group one. It runs the filter separately for each person in the group, so using assignee = currentUser() in the filter means it only notifies the user of his/her assigned items, not the whole group's list.
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in talking to 20 people planning t...
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
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs