Three Cerb4 behaviors that make you think it’s broken
Community, Tips & Tricks September 16th, 2008
posted by Joe GeckYou can’t help but run into some issues in your first weeks of test driving Cerb4, whether you’re trying to do something trivial or just playing around to see how a feature works. Once you find a potential “bug” you’ll probably start by searching the forums, then writing in to support and maybe even adding it to JIRA yourself. But don’t pull the fire alarm too quickly! The problem is there’s a lot going on beneath the surface that you may not be aware of.
What’s the point of all this, you ask?
To show you why things are not working like you would expect. Because if you’re familiar with how the Helpdesk works under the hood, you will know immediately if you fell on a real bug or a false positive. Hopefully this will all make sense once I shed light on a few of these important behaviors in Cerb4.
Behavior #1: “Deleted” tickets are only removed from the Helpdesk after a set number of days with no new messages.
I’ve seen this one throw a few users for a loop in the past, who have stumbled on their “deleted” tickets still in the Helpdesk. Maybe they did a search for an old ticket ID, or were browsing all their tickets and noticed some X’d out. To see if you currently have any deleted tickets, do a search where ‘deleted = true (1)’.
Every 24 hours the Helpdesk purges deleted tickets, where 7 days have passed with no new messages. This is the default but If you want to adjust how often it wipes the Helpdesk, and how many days have to pass, click ‘helpdesk setup’, the ‘Scheduler’ tab and then the ‘Maintenance‘ link.
Holding onto deleted tickets for a few days definitely has its benefits, for one thing you get a “do over” in case you accidentally dismissed a ticket prematurely. But it’s nice to do some spring cleaning once in a while. Here’s a tip for reducing the size of your Cerb4 database, start by reporting all spam and deleting any irrelevant tickets you no longer need. Then under “Maintenance Settings”, set the ‘days of inactivity’ to zero, save changes and click ‘run now‘. Don’t forget to change it back up to a reasonable number of days when you’re done!
Behavior #2: Flood protection potentially stops auto-replies from being sent by the Helpdesk.
I’ll assume everyone is acquainted with flood protection and how vital it can be in preventing mail loops, e.g. two addresses auto-replying to each other back and forth. This is one of those behaviors users are surely familiar with, but simply forget about when testing their live Helpdesk.
I see this oversight pop up every so often in our forums. A person is configuring the group auto-response settings, and is experimenting to see if the “new ticket” and “close ticket” responses are working correctly.
To actually test it, they usually send a handful of tickets from their test e-mail address into the Helpdesk. By rapidly sending in new tickets and immediately closing them, they ultimately flood the Helpdesk. Of course at that point, they mistakenly think Cerb4 is broken when it ceases to consistently trigger auto-responses. In a real world scenario, any spammy addresses that flood the Helpdesk will be ignored and your real customers will get your auto-responses.
Behavior #3: E-mailing the Helpdesk from a worker address will cause “role reversal” issues, e.g. when the worker address replies, the Helpdesk thinks it replied.
Your organization’s workers are defined by an e-mail address in the Helpdesk, that’s their login to the system, their unique identifier if you will. What if you start using a designated worker address as an external test address for sending mail into the Helpdesk — is it too much of a stretch to assume some interesting results might occur?
This causes the “role reversal” problem: the Helpdesk thinks workers are sending outgoing messages when they are actually incoming messages. And after a few replies between your Helpdesk and your outside (worker) address, you’ll start seeing issues mysteriously pop up.
There’s even a couple of concrete examples in JIRA already that highlight this behavior. Look familiar?
CHD-570: Incoming/Outgoing labels are switched when an e-mail is sent to the Helpdesk from a worker address
CHD-617: Worker reply to Autoresponse email generates a new ticket
Bottom line, avoid using worker addresses as test recipients, otherwise you’ll start seeing unexpected bugs left and right.
So that’s it! If nothing else, now you can explain away the odd issues you may see when playing around with Cerb4. Just remember the Helpdesk isn’t broken, that’s by design.
-joegeck@wgm
Behavior #3 is a bug. Sure, there’s a workaround–don’t allow Workers to become Requesters–but this doesn’t work for everyone, as Mike Ellis points out in his comment in CHD-570, where he writes, “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.”
You’re right gglynn, there’s a small but vocal set of individuals who feel this is a bug. And rightfully so, the way they use the Helpdesk with 2 “independent” organizations (or teams) breaks the current design of Cerb4. I have a feeling this will eventually be fixed, so this may become moot in the future. I simply wanted to highlight odd behavior people in the forums have been bumping into for quite some time.
If you’ve been around the forums for as long as I have, you’ll see users regularly complain that they’ve stumbled on some kind of bug. The problem is usually they can’t point to exactly what’s causing it. That is they do not understand the “role reversal” concept defined in Behavior #3. Hopefully the original point of the article still gets through, which is if you see things breaking when testing your Helpdesk you’ll know the root cause. That’s more along the lines of the original intention, despite that behavior being considered a showcase of a workaround.
Of course as you pointed out they’re more than free to comment on the two bugs. It’s just nice to recommend they avoid it until a change is made. Stay tuned!
OK, more of a question than a comment; This is how my organization attempts to use Cerb2.6 and hopes to use Cerb4
We have two companies, most of the time the companies do separate work but sometimes a worker from one company will create a ticket for a worker in another company. Between the two companies there is one boss, he likes to be able to check where each customer issue/lead is up to by checking through the unassigned tickets. This also applies to when staff members are out on site or generally unavailable - our whole aim of using Cerberus is so we can keep conversations between customers in a central repositry where any staff member can find it.
For incoming mail this seems to work under cerb4 - the assignment notifications are great for me in particular as I don’t monitor Cerberus on a regular basis - I’m even thinking of writing a web service with a windows client to notify me of new messages in Cerberus.
Here is the big question(s): Joe says not to use a worker’s email address for testing. Does that our clients can’t email individual email addresses directly? Everything just has to go to support@mycompany etc?
When I create a new email, I can’t find it. Here’s a scenario. I’m out on site, someone takes a call for me. They create a new email and set me as the next worker. Currently I don’t receive a notification, and to make matters worse the ticket goes in to some “Waiting” queue - When I arrive back at the office am I supposed to interrogate this Waiting queue? When my boss wants to see what I haven’t acted on is this where he should look? Can’t waiting items be in the general queues like in Cerb2.6?
I know this is a bit of a ramble but I’m trying to get my head around Cerb4. I hope someone can help : )
Yeah this is really a massive 2-3 part question. Let me see if I can answer them for you.
1) Is it possible for 2 companies to use the Helpdesk to communicate between workers from opposite sides
As I’m sure you read in the comments, gglynn pointed out that others feel this is a bug (referring to CHD-570 and specifically the comment from Mike Ellis). If you’ve read his comment he is in the exact same situation as you, basically where 2 companies want to use 1 Helpdesk. As I said in my comment that breaks the current design in that you are basically treating your workers as “customers”, by letting them e-mail into the Helpdesk from the outside.
However the WGM developers are aware of this desire and are going to fix the “role reversal” issues for the next major release. If you notice the 2 bugs I referenced, both have updated ‘Fix Version/s’ for Milestone #20. So long story short, as of right now you may run into some problems if a worker from one company creates a tickets for a worker in another company. But in the next release, behavior/bug #3 will be fixed, a worker will be in effect treated like a “customer” and will be able to freely mail the Helpdesk.
2) Can our clients e-mail individual addresses directly.
Just a little background: one of the advertised benefits of using a Helpdesk like Cerb4 is that individual worker e-mails are not exposed by forcing outgoing mail through a company address. So theoretically in an ideal setup you would only promote company addresses like support@, sales@, etc to your customers. As you stated sometimes it’s necessary for 2 company communication, or organizations simply like to allow e-mailing individual workers directly.
With that said, you CAN have clients e-mail individual addresses directly with no problem. The original point of the article was stating you should avoid e-mailing into the Helpdesk FROM an address already assigned to a worker. So that would be like if joe@gmail was one of your worker logins and was sending a message from Gmail into the Helpdesk (support@mycompany). A normal client should theoretically not be a worker in your Helpdesk, it should be a customer. If the customer is a worker you’re back to question #1 of course. I know this is a lot of double talk, I hope it makes sense. Bottom line, any potential pitfalls will be resolved when the “role reversal” behavior is removed.
I regret listing behavior #3 as something other than a bug, as WGM is now going to treat it as such. The point of the article as I’ve said was to enlighten people on WHY they are having potential problems. It was mainly for users already in the process of using Cerb4 and not to deceive customers interested in upgrading. If anything it did its job by generating user feedback questioning what I said, though it was probably more trouble than it’s worth. ;)
3) Creating a new ticket does not send notifications.
This issue was recently spotted by one of our users and has been filed into JIRA. What you see is entirely correct but I’ll clarify that by saying: creating a new ticket through any means (’send mail’, ‘log message’ or ‘quick compose’) will NOT currently send notifications. Ideally this will be fixed in an upcoming release.
http://www.wgmdev.com/jira/browse/CHD-841
As far as the “Waiting” queue, are you referring to the actual “Waiting for reply” status? Assuming there is no bug present, when creating new tickets you should be able to leave the status set to ‘Open’. By doing that the ticket will stay in the Overview sidebar under ‘Available’ and not ‘Waiting’. And if you are set as the Next Worker, it will be in the ‘Assigned’ section of the sidebar under your name instead.
Hopefully that answers all your questions, mribbons.
Joe,
Thanks so much for your reply to my multipart query.
1) Actually we aren’t trying to email in to the helpdesk, we just want to be able to create a new ticket and have the notification sent to the requesters address so they know it is waiting without having to log in to Cerberus. Are “email in” and “create tickets” equivalent for you? I think I’m content to see what the next release offers and try that for now.
To further clarify, the same would apply for a single company with workers at different locations. If a client rings in and leaves a message, it would be nice to receive a notification on my handheld mail client which was triggered by another worker creating a ticket…
2) Understood.
3)
a) ok
b) I suspect my problem may have been that I didn’t enter a requester. I just entered a requester and noticed the link to View the message. Perhaps if the message isn’t created because the data isn’t valid, at least a generic error message should appear.
My company would still like to be able to create an internal ticket and set the next user without having to fill in a requester (Similar to part 1 I know.).. Anyhow this seems to be working fairly well so thanks.
Let me take a crack at these:
1) “Actually we aren’t trying to email in to the helpdesk, we just want to be able to create a new ticket and have the notification sent to the requesters address so they know it is waiting without having to log in to Cerberus.”
This would be entirely possible, if the “notification on ticket creation” bug I mentioned in the last reply was fixed.
http://www.wgmdev.com/jira/browse/CHD-841
Once it is fixed, any ticket you create through a ‘log message’ or ’send mail/compose’ will generate a notification for your workers. Since you’re not familiar with Cerb4 and I’m not up on Cerb2, let me try to explain how you would setup notifications to make this happen. Notifications can come from a couple of places, your workers can subscribe to new mail from a group/bucket OR subscribe to any mail that’s assigned to them. So for your 2 company example, if you wanted to create a new ticket within the Helpdesk for another co-worker, you’d click ‘log message’. Then the co-worker would be notified if you moved the ticket into a group/bucket he was subscribed to OR if you set him as the ‘Next Worker’. Got it?
I have an upcoming blog post I’m working on that goes into the details of E-mail Notifications. So you may want to read through that once it’s published, it will give you a better idea of how notifications are handled in Cerb4.
3b) “I suspect my problem may have been that I didn’t enter a requester … at least a generic error message should appear.”
That’s definitely something were missing, there is no error message if you forget to add a requester. We previously added this to JIRA and it should be fixed in the next release.
http://www.wgmdev.com/jira/browse/CHD-690
3c) “My company would still like to be able to create an internal ticket and set the next user without having to fill in a requester”
Unfortunately for ‘log message’ to do its job properly it needs to include a requester. What you could do is simply make the worker the requester. Of course as you know this starts creeping back into the “role reversal” issues that could cause problems. But as I said that’s going to be fixed real soon, so ideally you should be able to get away with this eventually.
Let me know if I missed something, mribbons.
Thanks Joe, Looking forward to the next release.