Hi All,
I have started facing a weird issue since last 2 weeks in the Shared itop instance. Four 4 organizations are using User Request module flawlessly. When I onboard a new department (organization) for them SLA 75% and 100% emails are not working but its working for other 4 departments (Organizations).
I checked there is no problem with cron and backgound tasks as in case of others is working. Does these parameters can cause problem.
Following are my parameter settings
'cron_max_execution_time' => 250,
'max_execution_time' = 300
(apache) 'timeout' = 300
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am also having the same problem.!
I had config notification with 25% TTO, but it dont send mail. I had check cronjob or trigger/action still works normally.
Who can help me fix incident?
I'm using itop version 2.7.1 and extension "combodo-mail-to-ticket-automation-3.1.0".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
$oTriggerSet = new DBObjectSet(
DBObjectSearch::FromOQL("SELECT TriggerOnThresholdReached AS t WHERE t.target_class IN ('$sClassList') AND stop_watch_code=:stop_watch_code AND threshold_index = :threshold_index"),
array(), // order by
array('stop_watch_code' => $sAttCode, 'threshold_index' => $iThreshold)
);
while ($oTrigger = $oTriggerSet->Fetch())
{
$oTrigger->DoActivate($oObj->ToArgs('this'));
And change it:
$oTriggerSet = new DBObjectSet(
DBObjectSearch::FromOQL("SELECT TriggerOnThresholdReached AS t WHERE t.target_class IN ('$sClassList') AND stop_watch_code MATCHES :stop_watch_code AND threshold_index = :threshold_index"),
array(), // order by
array('stop_watch_code' => $sAttCode, 'threshold_index' => $iThreshold)
);
while ($oTrigger = $oTriggerSet->Fetch())
{
try
{
$oTrigger->DoActivate($oObj->ToArgs('this'));
}
catch(Exception $e)
{
utils::EnrichRaisedException($oTrigger, $e);
}
Has this error been fixed?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi All,
I have started facing a weird issue since last 2 weeks in the Shared itop instance. Four 4 organizations are using User Request module flawlessly. When I onboard a new department (organization) for them SLA 75% and 100% emails are not working but its working for other 4 departments (Organizations).
I checked there is no problem with cron and backgound tasks as in case of others is working. Does these parameters can cause problem.
Following are my parameter settings
'cron_max_execution_time' => 250,
'max_execution_time' = 300
(apache) 'timeout' = 300
This is becoming a P1 issue now as clients are missing SLA notifications. We need some guidance on how to troubleshoot it, any help is appreciated.
Any suggestion is highly appreciated.
I am also having the same problem.!
I had config notification with 25% TTO, but it dont send mail. I had check cronjob or trigger/action still works normally.
Who can help me fix incident?
I'm using itop version 2.7.1 and extension "combodo-mail-to-ticket-automation-3.1.0".
I find in /core/ormstopwatch.class.inc.php
Code:
$oTriggerSet = new DBObjectSet(
DBObjectSearch::FromOQL("SELECT TriggerOnThresholdReached AS t WHERE t.target_class IN ('$sClassList') AND stop_watch_code=:stop_watch_code AND threshold_index = :threshold_index"),
array(), // order by
array('stop_watch_code' => $sAttCode, 'threshold_index' => $iThreshold)
);
while ($oTrigger = $oTriggerSet->Fetch())
{
$oTrigger->DoActivate($oObj->ToArgs('this'));
And change it:
$oTriggerSet = new DBObjectSet(
DBObjectSearch::FromOQL("SELECT TriggerOnThresholdReached AS t WHERE t.target_class IN ('$sClassList') AND stop_watch_code MATCHES :stop_watch_code AND threshold_index = :threshold_index"),
array(), // order by
array('stop_watch_code' => $sAttCode, 'threshold_index' => $iThreshold)
);
while ($oTrigger = $oTriggerSet->Fetch())
{
try
{
$oTrigger->DoActivate($oObj->ToArgs('this'));
}
catch(Exception $e)
{
utils::EnrichRaisedException($oTrigger, $e);
}
Has this error been fixed?
This bug was fixed in 2.7.2.