say IT works from 8AM-5PM.
We notify our support staff on ticket creation in the "Hotline" project. That's easy.
What's more nasty is we'd also like to escalate issues BUT only during working hours, i.e. issues raised after 5PM or before 8AM (mo-fr) should send their first reminder at 8:30AM (first reminder delay = 30 minutes). Same thing for escalations after 1 hours and after 3 hours.
It's not nice but I can do this using at least 10 filters with subscriptions:
- one filter running once at 8:30AM checking all that happened during the night
- one filter running regularly during business hours
And all of that for all 3 escalation levels. Additionally one extra filter for Mondays that checks the weekend too.
It feels too complicated. Is there some more easy way I can do this aside from writing my own Jira service which I wouldn't consider easy...
I am not sure how you have implemented "escalations" in your instance. At Atlassian, an escalation moves an issue into a different workflow status. And the notifications are then controlled by the transition and the notification scheme.
It sounds like your notification system is currently based on a filter subscription sent out to all employees on a regular basis with a list of all issues which are affected.
If my understanding of your system is correct, then I think the method you suggested is a valid way to approach this. Another solution which is not easy, but would be easier long term, would be to write just 1 abstract Jelly script and then have it run every 5 minutes using services. Have it read your parameters for notification in from a config file where you define the formatting. Then adjusting this will simply mean adding 1 line in a text file.
Another option would be to use an external notification system which has the configuration options you need and can pull data from JIRA via the REST API.
we haven't implemented escalations yet. This is an inital design decision.
I've read JIRA as a Support System and How Atlassian Uses JIRA for Support but it doesn't quite cut it.
In a first step it's mainly notifying about issues that have been left unassigned for certain durations.
JQL is not flexible enough to put everything into one filter. Like checking the actual time it is run and adding conditionals based upon that.
One could do with several filters using JQL each using a different schedule to run them, as I described before. But lots of filters with complicated schedules and JQL at its limits doesn't feel to me like the way to go.
Jelly seems even less flexible:
- can't create a specific schedule, only intervals using the service runner,
- the only usable thing here would be TransitionWorflow,
- aside from RunSearch, which again points to a JQL filter, which (see above) is not flexible enough.
In the end, I think we're going to use PHP pulling data from JIRA via the REST API. Sure, that's still calling JQL, but I can build it dynamically.
If I was more fluent in Java I'd go with creating a Jira service...
Now, notifications might work well like that. However I still have to think about sensible filters (views) that represent each of these escalations. One could either keep the complexity of those views to a minimum or have the PHP add some tag to the issues once it has touched them and filter on that... the sky's the limit.
It's always strange that one seems to have requirements different from everyone else's ;-)
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
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