Matt> I have an email list that is mainly used for reporting issues. I Matt> want to automatically create tickets from emails to that Matt> list. However, that list also serves as a discussion list in Matt> some cases. So forwarding all messages to the list into my Matt> ticket system would mean that the discussion and replies would Matt> result in a fair number of bogus tickets.
You're screwed, since combing these two into one email address is going to be painful. Been there, done that. *grin* I really liked how RT 1.x handled emails into tickets, it was really sweet. Haven't managed to convince $WORK to use rt3.x (http://bestpractical.com) or OTRS yet. Matt> Although I think the clear answer is to break up the email list Matt> into a couple of separate lists (i.e., one for discussion and Matt> one for issue reporting), that doesn't seem like a good solution Matt> in this case due to the email list itself acting as an internal Matt> brand that would be hard to reproduce with new lists. So which has priority? Making the list handle tickets, or keep the discussion? If it's mostly for tickets (in an ah-hoc manner currently), then making it into a ticketing system is a good idea. Move the discussion off to a new, well publicized list and you're good to go. Matt> Anybody have good ideas on this? Don't try to combine them. Matt> I have an idea but I suspect it is absurd over-engineering: My thoughts too. Why go through all that pain when you can simply re-train your users by feeding them cookies? Put in the name of the discussion list in all emails returned by the ticketing system. Better yet, make it so that people can just reply by email to tickets and have the ticketing system track the conversation. Very nice. John _______________________________________________ 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/
