RE: More Eventum bugs and feature requests - J. Steinbachs - com.mysql.lists.eventum-users

6 messages in com.mysql.lists.eventum-usersRE: More Eventum bugs and feature req...

From	Sent On	Attachments
Phillip Steinbachs	13 Jul 2004 19:24
Phillip Steinbachs	13 Jul 2004 20:57
Joao Prado Maia	13 Jul 2004 21:06
Joao Prado Maia	14 Jul 2004 06:40
J. Steinbachs	14 Jul 2004 08:42
Joao Prado Maia	14 Jul 2004 14:29

Subject:	RE: More Eventum bugs and feature requests
From:	J. Steinbachs (je...@compbiology.org)
Date:	07/14/2004 08:42:37 AM
List:	com.mysql.lists.eventum-users

I was under the impression that this list was for users and user support. Wouldn't this sort of discussion be more appropriate on eventum-devel?

-jennifer

On Wed, 14 Jul 2004, Joao Prado Maia wrote:

Phil,

I guess that would work also, and would be more consistent. However, I personally like the ability to just switch on the fly, as it is one step shorter in getting to where I want to be.

Well, that makes sense. You would usually only switch the project in the issue details page to go to the list of issues and work on something else.

My definition of an external customer is someone who does not have access to the web interface. The following events occurred:

- External customer sent E-mail to support alias - E-mail was associated as a new issue - I'm the only staff member on the notification list - External customer is Other: in the notification list - I reply to external customer - External customer replies to my reply - Eventum auto associates the E-mail to the issue - External customer receives a duplicate copy of their reply to me, that appears to be sent from "Joe User <supp...@ourdomain.com>"

This exact thing was happening before, but only when a reply was made to an unassociated E-mail. In this case, the E-mail is assigned to an issue, so I don't know what's going on.

Yes, I'll try to reproduce this.

My users are demanding it, so if you don't want to add it, I will add it myself as a locally supported change. Personally, I don't care how it gets done, as long as I'm not spending more time fighting Eventum issues than I am solving real issues. I'm just a lowly sysadmin grunt after all, not a programmer. :)

You still didn't say exactly what you suggest for this problem.

While I understand your point, I think you've contradicted yourself a little bit. From my perspective, patches are pointless if they're for "very personal" changes, because they would only be applicable to us internally. I don't want to waste effort creating and submitting patches if they're not going to be generally useful to others.

Well, I meant patches as in new reports. From experience, creating the reports for someone is never final, and there's always someone who wants something different. So my point is that if I spend time developing something for your needs, some other user will ask for a different report, and so on. So I rather leave the reporting system as it is, and leave further improvements to come from the community at large.

So why did you bother adding the "automatically close confirmation popup windows" in the first place? From a UI perspective, it seems pointless to have it as it doesn't solve the real problem. My suggestion is to change it to "Only generate popup windows on errors?".

Because we have internal users who want to see the popup's message, even if it is a positive one. Even if I implement what you are requesting, the popup will still have to show up, since the popup has the code that process the form's submissions.

For some of our staff members it is, and for the exact reason you mention. The notification list is not static and can change during the course of resolving a particular issue. It is useful to keep a notification list history. Our staff want to be certain of who notes go to, because of the [sometimes] sensative information they enter in those fields regarding external customers.

Ok, I'll add it to the TODO list then.

--Joao

!DSPAM:40f529e363121534866497!