Add Enabled flag to AlarmGroups; filter disabled groups from AlarmOperation

[Copilot]

AlarmGroups had no enable/disable mechanism, so AlarmOperation always evaluated all alarms regardless of intent. This adds an Enabled flag with default true (preserving existing behavior) and filters disabled groups out of alarm evaluation at the SQL level.

Data Model

• Added Enabled BIT NOT NULL DEFAULT(1) to AlarmGroup table
• AlarmGroup and AlarmGroupView C# models updated with [DefaultValue(true)] public bool Enabled { get; set; }

SQL Views

• ActiveAlarmView: both UNION branches now exclude disabled groups — AlarmFactor branch uses INNER JOIN AlarmGroup AG ON ... AND AG.Enabled = 1; synthetic-factor branch uses WHERE AlarmGroup.Enabled = 1. This is where HIDSAlarmOperation queries, so no C# changes are needed.
• AlarmGroupView: exposes Enabled column for UI consumption

(
    SELECT AF.ID, AF.Factor, AF.AlarmGroupID, AF.SeverityID
    FROM AlarmFactor AF
    INNER JOIN AlarmGroup AG ON AF.AlarmGroupID = AG.ID AND AG.Enabled = 1
    UNION
    SELECT NULL, 1.0, AlarmGroup.ID, AlarmGroup.SeverityID
    FROM AlarmGroup
    WHERE AlarmGroup.Enabled = 1
) AlarmFactor LEFT JOIN ...

Migration

• AlarmGroup-Enabled-Migration.sql: idempotent ALTER TABLE (column add guarded by IF NOT EXISTS), followed by drop/recreate of both views — safe to run against existing databases

API / TypeScript

• IAlarmGroup and IAlarmGroupView interfaces gain Enabled: boolean
• New groups initialized with Enabled: true in Redux reset action

UI (SPCTools)

• GeneralSettings.tsx: CheckBox for Enabled in the wizard's general settings step
• AlarmGroup.tsx: Status column (Enabled/Disabled badge) in the list view; Enabled added as a searchable field

Original prompt

Repo: GridProtectionAlliance/openXDA (C#, TSQL, TS).

Goal
Add an enabled flag to AlarmGroups and make AlarmOperation only consider alarms that are enabled.

Background / Current behavior

• Alarm groups currently have no enable/disable mechanism.
• AlarmOperation currently considers all alarms in groups.

Required changes

1. Data model / schema

• Add a boolean Enabled flag to AlarmGroups.
• Default should preserve existing behavior for existing rows (i.e., Enabled = true).
• Add/update any required database migration scripts (TSQL) and ensure deployments handle existing databases.

2. Server-side logic (C#)

• Update AlarmGroup entity/model to include Enabled.
• Update AlarmOperation logic so it only evaluates alarms associated with AlarmGroups where Enabled = true.
• Ensure queries and joins filter out disabled groups efficiently (prefer SQL-side filtering).

3. UI (TypeScript/HTML/CSS) if applicable

• If the repo has an AlarmGroups management UI, add a toggle/checkbox for Enabled.
• Ensure disabled groups are visually indicated and excluded from alarm operations as per server behavior.

4. API / contracts

• If AlarmGroups are exposed via API, include Enabled in DTOs.
• Ensure backward compatibility (clients not sending Enabled should create groups enabled by default).

5. Tests

• Add/update unit/integration tests verifying:
  • Newly created AlarmGroups default to Enabled.
  • Disabled groups are not considered by AlarmOperation.
  • Re-enabling restores consideration.

Acceptance criteria

• AlarmGroups table (or equivalent) has an Enabled column with default true.
• AlarmOperation ignores alarms from disabled groups.
• UI/API can set Enabled.
• All tests pass and no regressions for existing deployments.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Add an Enabled Flag to the AlarmGroups, such that the AlarmOperation only considers Alarms when they are enabled

Assistant: I’ve kicked off the change request and am now waiting on your accept/reject response to proceed with implementing the Enabled flag for AlarmGroups and updating AlarmOperation to ignore disabled groups.

This pull request was created from Copilot chat.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.