> 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 <support@stripped>"
> 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
> For some of our staff members it is, and for the exact reason you
> 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.