If you do end up doing this, I suggest a way to make your ticket system de-duplicate based upon subject. That way, any replies (assuming they keep the same subject) would only generate 1 ticket.
On Mon, Jun 4, 2012 at 5:08 PM, Matt Disney <[email protected]> wrote: > Front-ending the list with my ticketing system is a thought. By raising > this point, though, you've helped me figure out I had some kind of assumed > requirement/interest about transparency that I would lose by going that > route. Still a possibility. Thanks. > > Matt > > On Mon, Jun 4, 2012 at 4:32 PM, Smith, David <[email protected]> wrote: > >> I’ve seen several ticketing systems that do more-or-less that, usually >> with just Subject: munging. The initial email, before being distributed to >> the list, gets something like [Ticket 12345] prepended or appended to the >> subject, and usually an automatic header/footer warning users to leave the >> ticket tag intact.**** >> >> ** ** >> >> You certainly could track Message-ID and References headers, and would >> probably get a slightly cleaner result, but it seems like a lot of extra >> work for relatively little extra benefit.**** >> >> ** ** >> >> (You could also, if beneficial, tie this into whatever back-end database >> you might have, so that the emails double as a ticket log.)**** >> >> ** ** >> >> David Smith**** >> >> ** ** >> >> ** ** >> >> *From:* [email protected] [mailto:[email protected]] >> *On Behalf Of *Matt Disney >> *Sent:* Monday, June 04, 2012 3:22 PM >> *To:* [email protected] >> *Subject:* [lopsa-tech] Email list to request ticket**** >> >> ** ** >> >> I have an email list that is mainly used for reporting issues. I want to >> automatically create tickets from emails to that list. However, that list >> also serves as a discussion list in some cases. So forwarding all messages >> to the list into my ticket system would mean that the discussion and >> replies would result in a fair number of bogus tickets. >> >> Although I think the clear answer is to break up the email list into a >> couple of separate lists (i.e., one for discussion and one for issue >> reporting), that doesn't seem like a good solution in this case due to the >> email list itself acting as an internal brand that would be hard to >> reproduce with new lists. >> >> Anybody have good ideas on this? >> >> I have an idea but I suspect it is absurd over-engineering: >> >> First I would add the ticket system email address to the email list in >> question. At this state, every message to that list would generate a ticket. >> >> Then I would add an email gateway program/script in front of the ticket >> system email address that would act as a conditional stateful filter. That >> program would receive the message, check the References and In-Reply-To >> headers against a list of previously seen Message-IDs. If there is a match >> against a previously seen Message-ID, the message is dropped. If there is >> no match, then the program adds this current Message-ID to the list and >> allows the message to pass through to the ticket system. >> >> At this point, hopefully I would get all new messages to the email list >> entered as a new ticket. But none of the replies to the email list. So I'm >> left with still having to resolve a small number of first messages in >> discussion threads, but overall that isn't so bad. I'm willing to accept >> that level of maintenance for the overall automation. >> >> That's a silly idea, right? >> >> Matt**** >> > > > _______________________________________________ > Tech mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ > >
_______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
