List:Eventum General Discussion« Previous MessageNext Message »
From:Jeffrey D. Wheelhouse Date:February 25 2005 11:05pm
Subject:24 Hours in the Life of Eventum 1.4
View as plain text  
(Look out, he's a rambler.)

Hello,

Just realized that there was a list for this program and it appears 
people actually read it.  I apologize if I am about to say things that 
have been said before.  It's all in the nature of relating my experience.

I set up an Eventum site a couple of months ago, because I needed a 
place to throw up a to-do list in a shared place for some projects.  It 
seemed to work OK, if fairly slowly.  I've got to think a product put 
together by the MySQL has pretty good SQL indexes, so I'm not sure what 
the problem is there.  Never bothered with the email feature; it didn't 
work and I wasn't in the mood to read directions.  Didn't need it, 
didn't care.  It did what I wanted.

That was 1.3.1, and I quickly ended up doing some hacking to carve out 
the "excess" columns in the "List Issues" panel.

It sat for awhile, doing exactly what it was supposed to do, but then I 
got an itch to try to make it do the same thing, but for a much larger 
company.  So I upgraded to 1.4 yesterday, found out that the List Issues 
was now configurable (good job!), and I managed to get the email working 
(I actually read the directions this time).

Right after I set up all the cron jobs, I started getting messages. 
Lots of messages.  All in all, with "copy all messages to..." and "email 
errors to..." it dumped about 20,000 messages into my mailbox over the 
course of a couple of hours.  I don't know if it was trying to make up 
for lost time or what, but it also sent several hundred to people who 
had been my friends just the day before.  Oh well, my bad for not 
reading the directions the first time.

While dealing with email I came across several issues:

1) The cron jobs use the web page error handling scripts, leading to 
further explosions because things like $_SERVER["HTTP_USER_AGENT"] don't 
exist.

2) It sends lots of messages with obviously undefined variables.  "Dear 
user, this is in response to the issue you reported from ."

3) Trying to use self-signed SSL for imap tosses up some kind of error 
from the PHP imap module.  Might have been "bad transport" or something 
like that.  It had about half of something that looked like "selfsigned}."

4) It takes weird errors about "bad message number" in the cron job (I 
think it's the one that reads the mail, not the one that sends it.)

5) The "is this a reply?" detection misses about 80% of replies, opening 
new tickets.  This is the show-stopper problem.  I can mark these as 
duplicates, but there's no way to actually coalesce the messages or 
their information back into the existing ticket short of cut-and-paste. 
   And both the end users and the developers want and need to interact 
with this system primarily via email.

I'm sure I can make this work better for me, but where are you all at on 
this?  How could I do whatever I do for us so that it will be most 
helpful elsewhere?  The issue_#@yourdomain.com idea is not a bad one, 
but that would be problematic in my email setup, and the rest of the 
world seems to be able to get by with figuring it out from a single address.

I apologize that due to the volume of mail all the messages with the 
actual error messages got axed.  I'll be adding some more tickets this 
evening, and if anyone thinks its worthwhile, I'll try to capture any 
fun errors I come across.

Other thoughts / observations / suggestions

- The web side seems ok to very good.  The performance is a little 
worrisome; there are 200 tickets in there now and it drags.  If I go 
live on this and it goes to 2000, what happens?  But I am not ready to 
blame that on Eventum right now; there are plenty of other possible 
causes; Eventum is here in part to help us keep track of all of them.

- It is a little frustrating that even the administrator cannot delete 
tickets.  I understand the principle of an indelible audit trail, but I 
have like 100 "this is a test" tickets that will sit around forever 
because the email replies didn't thread.  What are the implications of 
deleting them from MySQL?

- Please add a "priority" field to project_priority, and sort based on 
it.  The "priorities go in order of how they were added" approach caused 
some extra grief when we decided to add a would-be higher-priority category.

- I have a developer who refuses to use anything but oddball Unix 
browsers, and he complains that the font size is unreadably small.  I am 
not sure if indicates a problem with Eventum, the browser, or the developer.

- It tries in a couple of places to change timeout values when running 
in safe_mode, which is a no-no.  Other than that, it seems to work fine 
in safe mode.

- Testing the mail config dies with no diagnostic if the IMAP PHP 
extension is not loaded.  (Yeah, I know, RTFM.)

- I took a couple of SQL errors when dealing with issues that had no 
category or user or something assigned..  the lack of quotes and 
escaping, which is probably also a security issue, was leading to SQL 
queries like 'WHERE blah = AND otherblah IS NOT NULL'

- issues sometimes "leak" from one project and are visible in another; I 
noticed this in the reporting area

- the ability to make mass changes to issues (close, change category, 
change priority)

Are these fixable issues?  Eventum seems like it's right about at the 
level of featurefulness and complexity that I want for this company and 
its user base at this point, and it is very configurable and allows lots 
of really good trade-offs.  Plus it looks professional and yet is 
lightweight.

I don't mind putting some amount of effort into some of this, but the 
degree of change between 1.3.1 and 1.4 was enough that I am wary of 
maintaining a bunch of local patches.

I'd be happy to submit patches for whatever changes I've made so far, or 
make in the future, if they're useful.  Thusfar they've been a bit 
rough, though, as I pretty much cut my way through the system with a 
torch to get to a working install ASAP.

Basically I really like this program, which is a direct result of all 
the obviously hard work that has gone into it.  Thank you to everyone 
responsible for that!

On top of that, from my brief whiff, Eventum smells architecturally 
friendly to me and mine, and to our way of thinking and developing.  So 
I would like to find a way to polish out some of the burrs and stick 
with it.

Anybody have any thoughts about how to get there from here?

Thanks for your attention and thanks in advance for any suggestions!

Jeff

-- 
Jeff Wheelhouse
jdw@stripped
Thread
24 Hours in the Life of Eventum 1.4Jeffrey D. Wheelhouse26 Feb
  • RE: 24 Hours in the Life of Eventum 1.4Joao Prado Maia26 Feb
    • Re: 24 Hours in the Life of Eventum 1.4Jeffrey D. Wheelhouse26 Feb
      • Re: 24 Hours in the Life of Eventum 1.4Elan Ruusam√§e27 Feb
      • RE: 24 Hours in the Life of Eventum 1.4Joao Prado Maia2 Mar
        • Re: 24 Hours in the Life of Eventum 1.4Jeffrey D. Wheelhouse2 Mar
          • RE: 24 Hours in the Life of Eventum 1.4Joao Prado Maia2 Mar
            • Re: 24 Hours in the Life of Eventum 1.4Jeffrey D. Wheelhouse2 Mar