Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 457069

Summary:	Use Initial Response Time SLA in service breach calcuations if the Subsequent SLA time is NULL
Product:	[Retired] JBoss Customer Support Portal	Reporter:	Mike Amburn <mamburn>
Component:	Notifications	Assignee:	JBoss CSP Bug Watch List <csp-bugs-watch>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	low	Docs Contact:
Priority:	medium
Version:	1.3.8	Keywords:	FutureFeature
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:	1.3.9	Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-07-29 14:53:45 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	457070

Description Mike Amburn 2008-07-29 14:51:58 UTC

When calculating the SBT of a NEW case, the calculation rule is based on the
time of the case creation + the initial response time of this case. The initial
response time is defined as a combination of the generic customes' SLA and the
severity level of the case. Please see all values at :
https://www.redhat.com/support/policy/sla/production/ (Std and Premium)

For subsequent response times, these should default to the same values as for
the initial response time. If the system does not find specific values for the
subsequent response time, then the value for subsequent response time is the
same as the one used for initial response time.

SBT should recalculate on each transition to WoRH.

-----

Moved manually from Jira (JBNET-2235)

Comment 1 Mike Amburn 2008-07-29 14:52:34 UTC

(per nlugert via Jira:)

Modified SubsequentResponseTimeAction class to use initial_response_time if
subsequent_response_time is NULL or "none"
if(subResponseTime == null || subResponseTime.equalsIgnoreCase("none"))
subResponseTime = sCase.getInitialResponseTime();

To Test:
Create a case in the csp and wait for gk to run in QA.
Change subsequent_response_time in the tickets table to NULL or "none" or "NONE"
Add a comment to the ticket via I-T and change status to "Waiting on Customer"
Add another comment as a customer and wait for gk to run in QA
view the GK logs and you should see the subsequent response time being set for
the ticket (if the sub response time was NULL or "none" previously, it would not
set it)

Comment 2 Mike Amburn 2008-07-29 14:53:08 UTC

(per nlugert via Jira)

Changed createCase method in CaseManagementBean to set the subsequent response
time to the same as the initialResponseTime

ticket.setInitialResponseTime(entitlement.getInitialSev1());
ticket.setSubsequentResponseTime(entitlement.getInitialSev1());

https://jira.jboss.org/jira/browse/JBNET-2235?focusedCommentId=12407296#action_12407296

Comment 3 Mike Amburn 2008-07-29 14:53:31 UTC

(per nlugert via Jira)

changed createCase method in CaseManagementBean to use initialResponseTime for
subsequentResponseTime and also changed GK to set subsequentResponseTime to
initialResponseTime if subsequentResponseTime is null or "none", this will only
apply to cases created before the caseManagementBean fix

https://jira.jboss.org/jira/browse/JBNET-2235?focusedCommentId=12407297#action_12407297

Comment 4 Mike Amburn 2008-07-29 14:53:45 UTC

Should be included in 1.3.9 according to Jira.
https://jira.jboss.org/jira/browse/JBNET-2258