-
Suggestion
-
Resolution: Won't Do
-
None
-
None
NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.
This is a big wish, I've broken it down into subsections.
== Root Cause ==
We currently use two systems for managing issues with our customers, and our products. We use Jira on the "project management" side of things (assigning and tracking issues, release management, ie: your classic Jira usage). We also use a trouble-ticket system (OTRS http://otrs.org/) to handle all our incomming "support" email.
There is some overlap between these two systems: basically, we will often have a support email that we want to turn into a bug or feature request. In this case, we manually create a JIRA and say "see ticket number 1234".
Since there is some overlap, we (of course) wish that it was just the one tool.
== The Wish ==
This wish comes in 3 parts:
1) intelligent inbound email processing
JIRA does most of this already, but for completeness:
a) thread tracking (OTRS does this by prepending a [TICKETNUMBER] to the subject field in replies, which is entirely adequate).
b) inbound sorting: sort email into different queues (projects?) based on header info (specifically the To field) . It is not enough to sort on the pop account, as we have multiple email aliases mapped to the same pop box.
2) outbound email
A way of being able to reply to a "thread" and have the email sent to the originator of the ticket. We don't want to create real jira users for all of email correspondants. As I write that, I'm imagining a special kind of issue-type, where I can "reply" similar to "add comment" but I also have To, CC, Subject fields, etc.
3) ticket management, escalation
A good ticketing system should force you not to forget to reply to unanswered email, so alerts and escalations are a must. OTRS has this feature where it won't show you the inbound queues unless you answer the escalated emails first. (This is both painful and desired :| )
and a 4th sneaky wish:
4) all this should be built into jira so I don't have to faf around writing plugins
== Misc ==
I can't make up my mind if this functionality would be easy to add to JIRA or not.
I have this feeling that the ticket "queues" are different to a JIRA "project". Or at least, I can seem myself changing the project of a ticket quite often (as customers sometimes send emails to the strangest of email addresses).
I was finally prompted to raise a JIRA for this feature after reading http://weblogs.asp.net/ericjsmith/archive/2005/04/12/400011.aspx
(This issue could be attached to JRA-2326)
- is incorporated by
-
JRASERVER-2326 Advanced email support
- Gathering Interest
- relates to
-
JRACLOUD-6402 [wish] JIRA meets email/ticket tracking
- Closed
-
JRASERVER-6495 Organise issues into containers or queues
- Closed
[JRASERVER-6402] [wish] JIRA meets email/ticket tracking
Workflow | Original: JAC Suggestion Workflow [ 3055245 ] | New: JAC Suggestion Workflow 3 [ 3682115 ] |
Status | Original: RESOLVED [ 5 ] | New: Closed [ 6 ] |
Workflow | Original: Confluence Workflow - Public Facing v4 [ 2606528 ] | New: JAC Suggestion Workflow [ 3055245 ] |
Workflow | Original: JIRA PM Feature Request Workflow v2 - TEMP [ 2584247 ] | New: Confluence Workflow - Public Facing v4 [ 2606528 ] |
Status | Original: Closed [ 6 ] | New: Resolved [ 5 ] |
Workflow | Original: JIRA Bug Workflow w Kanban v6 - TEMP [ 2361280 ] | New: JIRA PM Feature Request Workflow v2 - TEMP [ 2584247 ] |
Workflow | Original: JIRA Bug Workflow w Kanban v6 [ 2128842 ] | New: JIRA Bug Workflow w Kanban v6 - TEMP [ 2361280 ] |
Workflow | Original: JIRA Bug Workflow w Kanban v6 - TEMP [ 2091719 ] | New: JIRA Bug Workflow w Kanban v6 [ 2128842 ] |
Workflow | Original: JIRA Bug Workflow w Kanban v6 [ 888682 ] | New: JIRA Bug Workflow w Kanban v6 - TEMP [ 2091719 ] |
Description |
Original:
This is a big wish, I've broken it down into subsections. == Root Cause == We currently use two systems for managing issues with our customers, and our products. We use Jira on the "project management" side of things (assigning and tracking issues, release management, ie: your classic Jira usage). We also use a trouble-ticket system (OTRS http://otrs.org/) to handle all our incomming "support" email. There is some overlap between these two systems: basically, we will often have a support email that we want to turn into a bug or feature request. In this case, we manually create a JIRA and say "see ticket number 1234". Since there is *some* overlap, we (of course) wish that it was just the one tool. == The Wish == This wish comes in 3 parts: 1) intelligent inbound email processing JIRA does most of this already, but for completeness: a) thread tracking (OTRS does this by prepending a [TICKETNUMBER] to the subject field in replies, which is entirely adequate). b) inbound sorting: sort email into different queues (projects?) based on header info (specifically the To field) . It is not enough to sort on the pop account, as we have multiple email aliases mapped to the same pop box. 2) outbound email A way of being able to reply to a "thread" and have the email sent to the originator of the ticket. We don't want to create real jira users for all of email correspondants. As I write that, I'm imagining a special kind of issue-type, where I can "reply" similar to "add comment" but I also have To, CC, Subject fields, etc. 3) ticket management, escalation A good ticketing system should *force* you not to forget to reply to unanswered email, so alerts and escalations are a must. OTRS has this feature where it won't show you the inbound queues unless you answer the escalated emails first. (This is both painful and desired :| ) and a 4th sneaky wish: 4) all this should be built into jira so I don't have to faf around writing plugins :D == Misc == I can't make up my mind if this functionality would be easy to add to JIRA or not. I have this feeling that the ticket "queues" are different to a JIRA "project". Or at least, I can seem myself changing the project of a ticket quite often (as customers sometimes send emails to the strangest of email addresses). I was finally prompted to raise a JIRA for this feature after reading http://weblogs.asp.net/ericjsmith/archive/2005/04/12/400011.aspx (This issue could be attached to JRA-2326) |
New:
{panel:bgColor=#e7f4fa} *NOTE:* This suggestion is for *JIRA Server*. Using *JIRA Cloud*? [See the corresponding suggestion|http://jira.atlassian.com/browse/JRACLOUD-6402]. {panel} This is a big wish, I've broken it down into subsections. == Root Cause == We currently use two systems for managing issues with our customers, and our products. We use Jira on the "project management" side of things (assigning and tracking issues, release management, ie: your classic Jira usage). We also use a trouble-ticket system (OTRS http://otrs.org/) to handle all our incomming "support" email. There is some overlap between these two systems: basically, we will often have a support email that we want to turn into a bug or feature request. In this case, we manually create a JIRA and say "see ticket number 1234". Since there is *some* overlap, we (of course) wish that it was just the one tool. == The Wish == This wish comes in 3 parts: 1) intelligent inbound email processing JIRA does most of this already, but for completeness: a) thread tracking (OTRS does this by prepending a [TICKETNUMBER] to the subject field in replies, which is entirely adequate). b) inbound sorting: sort email into different queues (projects?) based on header info (specifically the To field) . It is not enough to sort on the pop account, as we have multiple email aliases mapped to the same pop box. 2) outbound email A way of being able to reply to a "thread" and have the email sent to the originator of the ticket. We don't want to create real jira users for all of email correspondants. As I write that, I'm imagining a special kind of issue-type, where I can "reply" similar to "add comment" but I also have To, CC, Subject fields, etc. 3) ticket management, escalation A good ticketing system should *force* you not to forget to reply to unanswered email, so alerts and escalations are a must. OTRS has this feature where it won't show you the inbound queues unless you answer the escalated emails first. (This is both painful and desired :| ) and a 4th sneaky wish: 4) all this should be built into jira so I don't have to faf around writing plugins :D == Misc == I can't make up my mind if this functionality would be easy to add to JIRA or not. I have this feeling that the ticket "queues" are different to a JIRA "project". Or at least, I can seem myself changing the project of a ticket quite often (as customers sometimes send emails to the strangest of email addresses). I was finally prompted to raise a JIRA for this feature after reading http://weblogs.asp.net/ericjsmith/archive/2005/04/12/400011.aspx (This issue could be attached to JRA-2326) |
Link |
New:
This issue relates to |
Resolution | New: Won't Do [ 10000 ] | |
Status | Original: Open [ 1 ] | New: Closed [ 6 ] |