Cisco Bug: CSCtb62799 - Save alert frequency to DB incorrectly, cause alert got 0 value after L2
May 06, 2010
- Cisco Unified Communications Manager (CallManager)
Known Affected Releases
Symptom: Save alert frequency to DB incorrectly, cause alert got 0 value after L2 Conditions: In a RTMT from Althea or pre8.0 release, when an alert with Frequency (for example: CpuPegging) of "Trigger 'n' alerts within 'm' minutes" is selected and then the default frequency level (Trigger on every poll) of the alert is selected, then the value of "m" in the "Trigger 'n' alerts within 'm' minutes" is saved as 0 in the database. There are indeed two issues when "N alerts in M (non-zero) minutes" has been initial option, and user selects the "trigger per poll" option. (before L2 upgrade). However both are related to RTMT saving incorrect value to the DB. (a) M is incorrectly set to 0 and saved in the database. (b) the "canHaveInterval" is still set to true and saved in database (where as, it should have been set to false). This wrong value stored in DB causes the displayed to be wrongly displayed after the L2 has been completed.
Bug details contain sensitive information and therefore require a Cisco.com account to be viewed.
Bug Details Include
- Full Description (including symptoms, conditions and workarounds)
- Known Fixed Releases
- Related Community Discussions
- Number of Related Support Cases