This is a really interesting concept. How would you deal with a.) priorities, b.) due dates, c.) simultaneous multiple users, and finally d.) performance?
(The reason I ask about the last point is because we currently have ~200 non-closed (open, new, stalled, etc.) tickets, some of which have threads 20+ replies long. Even with an average of 2 replies per ticket, that's still 600 emails, which would have to be read in, parsed, and processed every time a user does anything. Admittedly for just updating tickets I'd assume it's ok if there's a delay, but when you're trying to read through a ticket's history or do some queue management, it sounds pretty ugly.) Nicholas > -----Original Message----- > That's no problem. There's a bunch of things you can do. The > procmailrc or the input script could simply pass on anything > that doesn't have at least one of a list of keywords (e.g. > the product name). You would still get the message in the > inbox but it wouldn't trigger the ticket routines. You might > get a few false negatives but you're almost guaranteed to > eliminate the spams. You can also whitelist senders you replied to. > > Mike _______________________________________________ New York PHP Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk NYPHPCon 2006 Presentations Online http://www.nyphpcon.com Show Your Participation in New York PHP http://www.nyphp.org/show_participation.php
