Getting ready to have our Customer Support team use OnTime. I have a general question about how to explan the difference between a Incident and a Bug and why we would want a customer to use one vs. the other via the customer portal.  To me an incident is a container where 'bugs' should really live.  So we should restricts customer portal users from entering bugs and just limit them to feature and incidents. Then a customer support person can look at the incident and then create a Bug once verified.  Is this how most people do it or am I missing something?

 

Ken

You have hit the nail on the head!

Grant your customers access to create an incident and then when it is verified as a defect, then you move / copy it to the defect section.

You can then allow the customer to view the defect as well as edit it or add additional attachments.

Ok - now to take this a little further... when I log into the customer portal the customer can see a bunch of fields like priority and assigned to etc... now I don't really want the customer to be able to fill this information in.. is there way to template the customer portal incident template?

Hello Ken,

There is a way to apply a separate set of field templates for Customer Portal users.

In the Windows client, right-click on a project and select 'Edit Project'. In the Web client, select the project and click the 'Edit Project' button.

You'll see a list of settings on the lefthand side of the Edit Project window. Select 'Customer Portal Settings'

Here you can assign a template of your choice for each item type which will only apply to your Customer Portal users.

 

Hope that helps, let me know if you have any further questions.
 

---

Thank you,

Tom Harder
Axosoft Support
support@axosoft.com
1.800.653.0024 option 3
--'Fear the Bug' Podcast--

We've been using OnTime for a few months now, but didn't enable incidents, just defects and features.  We're starting to get defect reports that are not really bugs but end user errors. I want to enable incidents and prevent end users from creating defects, so the defect database doesn't get cluttered up with a lot of junk.

I set up incident templates, etc but have a couple of questions.  First, what is the recommended way to handle this, move the incident to a defect, or copy it?  If the incident is copied, would it be more work to keep the defect and incident in sync (e.g. when its resolved, etc.)?  Or should you close the incident when its copied rather than move it?

Maybe I overlooked it somewhere, but is there some sort of "best practices" document? We're a small shop with a few developers but expect things to ramp up over the next few months. Right now we (the developers) are fielding all defect reports but we hope to have some support people doing first level support soon, and only alowing them to escalate something to a defect after its been verified.

Second, there is no Build Number field in a incident. Why? Wouldn't you want to know what version the incident is being reported for?  I created a custom field named Build Number for incidents, but when I move a test incident to a defect, the built-in Build Number defect field does not receive the data from the custom Build Number incident field.

Thanks.
Don

dcaton:

I set up incident templates, etc but have a couple of questions.  First, what is the recommended way to handle this, move the incident to a defect, or copy it?  If the incident is copied, would it be more work to keep the defect and incident in sync (e.g. when its resolved, etc.)?  Or should you close the incident when its copied rather than move it?

Maybe I overlooked it somewhere, but is there some sort of "best practices" document? We're a small shop with a few developers but expect things to ramp up over the next few months. Right now we (the developers) are fielding all defect reports but we hope to have some support people doing first level support soon, and only alowing them to escalate something to a defect after its been verified.

Second, there is no Build Number field in a incident. Why? Wouldn't you want to know what version the incident is being reported for?  I created a custom field named Build Number for incidents, but when I move a test incident to a defect, the built-in Build Number defect field does not receive the data from the custom Build Number incident field.

- We move them, but if the customer needs to see the status of them, then we copy them!

- You may be able to use the workflow to populate the build number. 

Hello dcaton,

Because OnTime is so versatile and can be configured in so many different ways in order to work with your existing process, there is no real recommended way of moving/copying over items from one type to another. I like what jpdp mentioned- they usually move their items, but in the case that their customer needs to still see that item, they copy it. I tend to advise towards copying instead of moving, so that the original item is kept intact- but it seems that in your case that suggestion may not be applicable.You might want to try OnTime for a while in order to decide which method would be more reasonable for you and your team.

Regarding the 'Build Number' field as a built-in field for the Incident type, I'm not certain why it was originally designed that way. I've talked to other customers who share your concern, and I believe they've submitted feature requests asking our developers to change this in future versions of OnTime. I suggest that you also make the feature request in our Customer Portal in order to communicate to our development team your concern with this field.

 

---

Thank you,

Tom Harder
Axosoft Support
support@axosoft.com
1.800.653.0024 option 3
--'Fear the Bug' Podcast--

Well since I started this thread I might as well chime in.  We are a very small development shop (2 of us) with 3 Account Managers.  The account managers would field calls from clients that are having issues.  If it is verified as something being wrong we enter it as an incident.  Then we used to copy it over as a defect.  But that became to cumbersome to manage because we had to change the status of the bug then the incident.  So now we just enter the defect as an incident when it relates to a client. The main purpose of using incidents is so we can track which of our clients is logging the most support calls and how much time have we dedicated to a client.  Now I wish Ontime had an easy way to run a report by client and all the work that is logged against an incident.

 But to save our sanity and not make double work this is how we using OnTime - overall we all love the product- it helps us stay organized and track what we are doing.