Issue Description:
In MWC and OWS, in the Alarm Queue (Summary by Master Customer style (aka. Queue Rollup)) a higher priority alarm was set as suspended if a lower priority previous alarm had been suspended. We made a change so that if any existing alarms are unavailable, then the new higher priority alarm is also unavailable. If no existing alarms are unavailable, then the new higher priority alarm keeps its current state. New lower priority alarms don't override the highest priority alarm's state.
Solution:
While investigating, we found that the function of the rollup regarding unavailable state was somewhat broken as well. We made a change so that if any existing alarms are unavailable, then the new higher priority alarm is also unavailable. If no existing alarms are unavailable, then the new higher priority alarm keeps its current state which resolves the reported issue. New lower priority alarms don't override the highest priority alarm's state.
Apply Fix:
- Replace AppServer.exe on all Application Servers, restart AppServer(s).
DevOps Work Items:
Bug 18491: High priority alarm being suspended automatically - Boards (azure.com)
Hotfix release-compatible files:
2.1.25: \\boldfiles\Release\Manitou\Release 2.1.0\Hotfixes\Bug-18491-high-pri-alarm-rollup-suspend-from-low-pri-alarm-issue\
