NYCPHP Meetup

[Michael B Allen]

On Fri, 18 May 2007 10:18:20 -0400
"Nicholas Tang" <ntang at communityconnect.com> wrote:

> 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.)

Hi Nicholas,

If you want a really sophisticated tracker then this solution would not
be for you.

You could do some of these thing though. You would need an actual database
but considering you need to consistently generate new ticket numbers, you
probably need one anyway. Then you could hang all sorts of ticket metadata
off of that. That information would not be accessible through email
however. There would have to be a separate web screen for that.

I'm sure there are a lot of people doing support entirely through email
right now (we are). So this is a nice gentle step up without changing
the procedures too much. Support personnel can continue to just do
everything with emails (but with an occasional ticket number fixup)
while devs can give interesting things a priority so that it shows up
in some colorful web table with priority, status, SquirrelMail links,
etc.

Than maybe later on when they want something more sophisticated they
upgrade to Eventum or Trac.

Mike

-- 
Michael B Allen
PHP Active Directory Kerberos SSO
http://www.ioplex.com/