You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The old module supported handled status based on the notification_period recorded in IDO.
This used SQL query mechanics to calculate if the service are in a period based on the IDO tables (which is only the very basic info: weekday and times)
LEFT JOIN (
SELECTtpo.object_id,
tpo.name1,
(
tpr.dayIS NOT NULLANDtpr.start_sec<= UNIX_TIMESTAMP() - UNIX_TIMESTAMP(UTC_DATE())
ANDtpr.end_sec>= UNIX_TIMESTAMP() - UNIX_TIMESTAMP(UTC_DATE())
) AS in_period
FROM icinga_objects tpo
INNER JOIN icinga_timeperiods tp ONtp.timeperiod_object_id=tpo.object_idLEFT JOIN icinga_timeperiod_timeranges tpr ONtpr.timeperiod_id=tp.timeperiod_idANDtpr.day= DAYOFWEEK(UTC_DATE())
WHEREtpo.objecttype_id=9ANDtpo.is_active=1
) tp ONtp.object_id=s.notification_timeperiod_object_id
Warning: Currently broken in icinga2
The text was updated successfully, but these errors were encountered:
The old module supported handled status based on the
notification_period
recorded in IDO.This used SQL query mechanics to calculate if the service are in a period based on the IDO tables (which is only the very basic info: weekday and times)
Warning: Currently broken in icinga2
The text was updated successfully, but these errors were encountered: