http://www.cerb4.com/forums/showthread.php?t=1159

I know these scenarios are different but I think the solution of figuring out to treat worker addresses (registered with the Helpdesk) the same as regular addresses would solve all these types of issues.

Hildy [WGM] acknowledged in the thread that this is the root cause, so it sounds logical to assume the situation transcribed below would be "fixed by removal" so to speak.

[[Quoted from thread]]

Team A can only access tickets in their group.

Team B can only access their tickets.

2 people in Team C can only access their tickets, and 2 people in team C are the only people who are on Team D.


Let's say someone from Team C (me) sends a ticket to Team A through external email to Cerberus (not logging a message and assigning it to that team). Team A sends me back a reply (setting the ticket as Waiting automatically). When I respond back to Team A - the response is copied back to my own mailbox, and the ticket remains in "Waiting" status.

This also happened when someone from Team B used external mail to generate a ticket for Team C: Replied copied to the senders mailbox (Cerberus not set to do this from what I can tell) and the ticket does not shift from Waiting to Not Waiting.

This is a very important part of the system. I am in a very similar situation where "Customers" of Team A are "Workers" in Team B, causing tickets sent to Team A not to be re-opened on a reply from worker in Team B. This is causing a lot of problems between the 2 teams and a break in communication. In my opinion, this bug needs to be fixed a bit sooner than "wishlist" please and thank you.

Side note: Workers used to be able to reply and re-open tickets through email. As a temporary fix, what revision was this last seen? I believe it was somewhere after build 600, about the same time the INBOUND and OUTBOUND color coding.

Thanks,
-Mike

Moved to Milestone #20. There may be increased interest from a recent blog post.

Sorry to bother again but can we bump this up. It is very annoying to have to manually search for and re-open tickets replied to by workers through email. I'm sure there are others that would agree.

I hoped this wouldn't be pushed to the back-burner, but it looks like that's the case. I think this is a more important issue that what you guys think. The ability to treat workers as customers is extremely important when you have multiple groups in one organization. I hope this gets bumped up.

Can we Please! work on this issue? I would have never implemented a multi-tier/group system if I knew this was going to happen...

I've added this back to my short list. I apologize for the delay!

From the build I'm working on:

[INFO]: [Parser] Starting Parser Task
[INFO]: [Parser] Reading watcher-as-req-reply.msg...
[INFO]: [Parser] Decoded! (5 ms)
[INFO]: [Parser] Handling an external worker response from jeff@localhost
[INFO]: [Parser] The external worker was a ticket requester, so we're not treating them as a watcher.

That's the best way I can discern the context of a worker reply right now. When a watcher is a requester on a ticket, their replies will be treated as those of a normal requester (even if they reply from the outside to a watcher email). For normal watcher email where they are not a requester, their replies will be treated as outgoing replies proxied through the helpdesk from an external source (as happened now).

This should remove the kludgy need for separate email addresses for workers and worker-requesters.

Ideally we'd be able to get some context from the e-mail headers being replied to, but we can't depend on external e-mail clients to include them.

Let me know if that works for you guys.

This should be fixed for 4.1 (finally).

Verified in stable build 877.

I tested all the original user cases as presented in the description AND in the comments, this included the Team ABCD test. Good news is that all tests had the same expected results, that is inbound and outbound labels were as they should be and waiting was set back to open (not waiting) status when appropriate.

Closing out!

Two linked threads notified of fix. We are done with this bad boy!