jmartin_mds

We have our tickets set up so that the client emails an address that's actually a distribution list. One member of the list is an inbox that's only used for retrieving emails via POP and turning them into tickets or ticket replies, and then the system sends a notification to all admins in that department who are selected to receive ticket notifications. All of this is working fine, and the unknown user bug is finally resolved, but there's an issue that's persisting. Back when we installed WHMCS 8.2 we noticed a bug that after a ticket comes in and is assigned to an admin, any further replies from the client only generate a notification for the flagged administrator. This behavior makes it very difficult for multiple techs to collaborate as there may be missed notifications, and from a management perspective it adds another layer on to our already heavy workload that I can't simply depend on the ticket notifications to keep track of things, I have to monitor the support emails separately as well to see when clients are replying to my staff. I had opened a ticket with WHMCS about this issue back in July and they basically told me it's a feature not a bug. #CORE-16853 and according to the reply I got from support, the developers said this is how it was always supposed to work (despite that not being what's STILL in the documentation) and that I could use the email Notifications system https://docs.whmcs.com/Notifications however this notification sends to all users, so the assigned admin gets two emails from WHMCS, and the secondary notification doesn't actually contain the ticket reply, just a notification that a reply was sent, which makes it nearly useless. I'd like to see WHMCS put this functionality back the way it was before, or like they did with the unknown reply bug, give us the option to opt in or out of getting all the notifications. I understand that having two techs get all replies may seem cumbersome, but for management it's essential for me to know what my team members are doing. If anyone has a hook for this in the meantime I'd be very curious to see it.

Thank you so much @123host! This is great! I added a couple little changes to limit it to just Failed Imports and to set a timeframe: foreach (Capsule::table('tblticketmaillog')->where('status', 'not like', '%Successfully%')->where('status', 'not like', '%Blocked sender%')->where('status', 'not like', '%Prevented an Auto Responder%')->where('email', 'not like', 'mailer-daemon%')->orderBy('id', 'desc')->limit(10)->get() as $msg){ /* Name */ if ($msg->name === $msg->email) $name = $msg->name; else $name = "{$msg->name} <{$msg->email}>"; /* Date */ $today = new DateTime(); $msg_date = new DateTime($msg->date); $interval = $today->diff($msg_date); $date_interval = abs($interval->format('%R%a')); if ($date_interval <= 14){ if ($date_interval == 0 && $interval->h < date('H')) { $date_interval = 'Today'; } else if ($date_interval == 0 && $interval->h >= date('H')){ $date_interval = 'Yesterday'; } else if ($date_interval == 1) $date_interval = 'Yesterday'; else $date_interval .= ' days ago'; $output .= " <tr> <td>$date_interval</td><td>$name</td><td><a href='#' onclick=\"window.open('/" . $GLOBALS['customadminpath'] . "/systemmailimportlog.php?display=true&id={$msg->id}','','width=650,height=400,scrollbars=yes');return false\">{$msg->subject}</a></td><td>{$msg->status}</td></tr>"; } }

@WHMCS John Thanks for leaving this bug unresolved. We've got clients pissed off at us. When we start losing business because WHMCS isn't functioning correctly should I just request a credit from you off our bill or should I loop my legal team in too?

If this is the best you can come up with that's really sad.

Ticket collisions? That's seriously the issue you're trying to "fix" by introducing a whole lot of new work on everyone's part? In five years I can count on one finger the number of times that's come up and it was an extremely unusual situation wherein a ticket from another vendor was forwarded to us and it happened to match an older ticket in our system, but even in that case the collision would still have happened in your new "feature" because they were both clients and the ticket import wouldn't have been blocked. If this is how WHMCS is planning to respond to customers now by ignoring our needs that's good information to have for me to plan out the future of my business.

Maybe, just maybe, you could listen your customers and put it back the way it was, the way it's always been, the way that we rely upon to effectively run our businesses. WHMCS isn't for lawyers or accountants or other industries that can lollygag when it comes to replies. We're in hosting and when things go wrong sometimes it needs attention immediately, and there is absolutely no way for us to know every person that every customer will ever involve. It's not realistic and it is affecting our business to the point where other options are getting to be worth the money. This is a once in a decade decision, so anyone who leaves isn't coming back. So maybe you should give us back the software that we're paying for instead of tacking on six more things that will break and telling us it's a feature when you KNOW its a bug. YOU KNOW ITS A BUG. The way I know you know? I have the confirmed bug reports! YOUR OWN TEAM CONFIRMED THIS IS A BUG! So stop blowing smoke up my a** and just fix the software like you've been saying you were going to and in fact did fix for a while before you broke it again!

This issue seems to be fixed, but there is a -new- email bug in 8.2.0 wherein if a ticket is assigned to someone and a client replies, the notification only goes to the flagged person and not the whole team. I opened a bug report with them and they confirmed, it's listed as CORE-16853. Doesn't look like it's in the changelog yet but I'd expect it'll be a few weeks until we see 8.2.1.

This bug is a killer for us. We discovered this when a ticket was opened and the client cc'ed a distro group on their team, and none of the team's replies were automatically imported. Several time-sensitive emails were missed, thankfully we were able to get things wrapped up successfully but finding out that this was expected behavior and not a bug was extremely disheartening. The notion is being floated to import those replies as separate tickets and that's almost as bad. If there's a ticket number in the reply, the reply should attach to the ticket, end of story. Now I have to watch for failed imports, waste time (and database lines) merging tickets. Just put it back the way it was!

The Ticket and Order count in the header on every page was a huge help to notice when new tickets come in and to keep track of statuses, etc. But when I add this code in to either nav.tpl or header.tpl I get the links but no number, there's nothing displayed at all. I can't seem to find any documentation on what the correct variable is to pull the number in. Someone who knows Blend please help! <div class="header"> <div class="logo"> <a href="index.php"><img src="templates/{$template}/images/logo.gif" border="0" /></a> </div> <div class="stats"> <a href="orders.php?status=Pending"> <span class="stat">{$sidebarstats.orders.pending}</span> {$_ADMINLANG.stats.pendingorders} </a> | <a href="invoices.php?status=Overdue"> <span class="stat">{$sidebarstats.invoices.overdue}</span> {$_ADMINLANG.stats.overdueinvoices} </a> | <a href="supporttickets.php"> <span class="stat">{$sidebarstats.tickets.awaitingreply}</span> {$_ADMINLANG.stats.ticketsawaitingreply} </a> </div> </div>

I have the same problem. On ours it looks like it's for products that have no module associated with them. Like OP, we don't use a module with these products. Hopefully a fix will be released soon--don't need to get a ton of these every time renewals happen.