Case management improvements

[john]

Looking for ideas on how to improve the Sugar Cases and Bug Tracker modules.

[ruchida]

I think each case should include a customer (prospect) name, impact, target release, cost, difficulty, and others by which an internal project can make an appropriate decision by generating some reports.

[PrimalBlue]

A few additional fields would be good for reporting:

1) Charge / No Charge (and cost / price)
2) Category
3) Time Spent on on the Case (it would be good if it could be a list, Then each tech can log a start/end time with a note of what they did on the case).

Some features:
Ability to route cases to uses based on a category and/or the assocaited contacts "Owner".
Ability to Escalate the case to the next tier of support
Reporting on Cases per contact, avg time to close, avg cost per case, etc.

[PrimalBlue]

Bug Tracking / Releases are kind of related to Cases so here are a few comments on that.

1) Create a Product as a top level then relate a release to those products.
2) Create a Feature/Fix list for each Release, giving a user the ability to add to that list
3) Add hours Est and Actual Hours for each Bug/Feature for reporting

[malcolmh]

Hi,

I would like the case management module to be enahnced with the following features:

1.
Contract Management module to be used by support users when answering support requests. This should include imformation about the contract itself, start/end date, Service Level Agreements SLAs, customer contact person who can address cases etc.

This imformation can be used by sales to address renewing contracts. As suggested in the Opportunity thread, contracts from competitors can also be logged here.

2.
Module showing lists of products and components sold to customer, which are then used in conversations with the customer.
Here competitor products sold to the customer should be logged as well.

This information can also be used by Sales & Marketing to identify potential cusotmers for new or imporved products.

Cheers Malcolm

[malcolmh]

Hi,

another suggestion for imrproving the case management module. To improve customer realtions it would be great if it was possible to automatically notify the customer of the status of the problem via Email, especially if the customer is returning goods that need repairs e.g. product has been received, work has started or work completed.

One our our potential clients has similar functionality in their system today.

Cheers Malcolm

[kredfield]

I just upgraded to 2.5.1 and Cases seem to have been relegated to 2nd-class citizen status - they are no longer available in the Category displays for an Account for example (but bugs is there?). Please fix - Cases are an important component of the system.

[JamieinNH]

I just upgraded to 2.5.1 and Cases seem to have been relegated to 2nd-class citizen status - they are no longer available in the Category displays for an Account for example (but bugs is there?). Please fix - Cases are an important component of the system.

< -- This Advice is coming from someone who has read hour 5 of the book "Learn PHP in 24 hours" so PLEASE MAKE A BACKUP before attemping this. If you break it, I am not responsible... I break enough of my own stuff.. IF someone from the SugarTeam sees anything wrong with this, please advise.. Thanks!

As a fix you can go to /modules/account/DetailView.php and edit it to include cases.

Towards the bottom of the file you will see this: ADD the LAST line of this to include Cases.

if(!empty($subactivities))$sub_xtpl->assign('SUBACTIVITIES', $subactivities);
if(!empty($subcontacts))$sub_xtpl->assign('SUBCONTACTS', $subcontacts);
if(!empty($subopps))$sub_xtpl->assign('SUBOPPORTUNITIES', $subopps);
if(!empty($subleads))$sub_xtpl->assign('SUBLEADS', $subleads);
if(!empty($subcases))$sub_xtpl->assign('SUBCASES', $subcases);
if(!empty($subproducts))$sub_xtpl->assign('SUBPRODUCTS', $subproducts);
if(!empty($subquotes))$sub_xtpl->assign('SUBQUOTES', $subquotes);
if(!empty($subaccounts))$sub_xtpl->assign('SUBACCOUNTS', $subaccounts);
if(!empty($subbugs))$sub_xtpl->assign('SUBBUGS', $subbugs);

ADD THIS:

if(!empty($subcases)) $sub_xtpl->assign('SUBCASES', $subcases);



Then, right above that code you will see this:

if(array_key_exists('Bugs', $modListHeader))
{
if($sub_xtpl->var_exists('subpanel', 'SUBBUGS')){
ob_start();
echo "<p>\n";

$focus_list = & $focus->get_bugs();
include('modules/Bugs/SubPanelView.php');

echo "</p>\n";
$subbugs = ob_get_contents();
ob_end_clean();
}
}

ADD THIS CODE:

if(array_key_exists('Cases', $modListHeader))
{
if($sub_xtpl->var_exists('subpanel', 'SUBCASES')){
ob_start();
echo "<p>\n";

$focus_list = & $focus->get_cases();
include('modules/Cases/SubPanelView.php');

echo "</p>\n";
$subcases = ob_get_contents();
ob_end_clean();
}
}


Then when you pull up an account, it should have the Cases attached.

Jamie

[Jollyblue]

[QUOTE=PrimalBlue]A few additional fields would be good for reporting:

1) Charge / No Charge (and cost / price)
2) Category
3) Time Spent on on the Case (it would be good if it could be a list, Then each tech can log a start/end time with a note of what they did on the case).
QUOTE]

Further to 3) above - if you modified History so that the case status was changed there - you would have something very close to a full audit-log of the case - very useful. So for example, being able to produce a report showing a timestamp for each case status change, and a brief note about why the status change (e.g. "Called customer, left message" -> Customer Pending).

-Keith

[kredfield]

< -- This Advice is coming from someone who has read hour 5 of the book "Learn PHP in 24 hours" so PLEASE MAKE A BACKUP before attemping this. If you break it, I am not responsible... I break enough of my own stuff.. IF someone from the SugarTeam sees anything wrong with this, please advise.. Thanks!
Jamie

Thanks Jamie, you are way ahead of me - you actually read.

Your changes worked like a champ, but upon inspecting the code it's clear that the Cases code got yanked for some reason. So I'd like to ask the PTB why? And can this be fixed? Cases is already feeling like the bastard stepshild of the system, and unfortunately it's key for us (and I'm sure many others). Why would listing Bugs on the User display be very useful (I'd argue that linkage should always be via a case...) for example...

If I had any freakin clue, I'd submit Jamie's code (with proper credit) back to the forge.

-Keith