Implement the central ConfigurationDatabase side of SMS notifications:
- NotificationConfiguration: EmailAddress now nullable (SMS-only recipients
carry a PhoneNumber, no email); add PhoneNumber nvarchar(32); add
SmsConfigurationConfiguration (AuthToken sized as the encrypted column,
mirroring SmtpConfiguration.Credentials; timeout/retry mapped REQUIRED for
ctor-default round-trip fidelity).
- ScadaBridgeDbContext: add SmsConfigurations DbSet, encrypt AuthToken at rest
via EncryptedStringConverter, and cover SmsConfiguration in the schema-only
secret-write guard.
- NotificationRepository: implement the four INotificationRepository SMS-config
methods (resolves the 4x CS0535), mirroring the SMTP methods' stage-only /
separate-SaveChangesAsync discipline.
- Migration AddSmsNotifications: idempotent (guarded) ALTER EmailAddress nullable,
ADD PhoneNumber, CREATE SmsConfigurations; Down reverses cleanly (backfills
NULL emails before restoring NOT NULL).
S1 made NotificationRecipient.EmailAddress nullable + added SmsConfiguration
and four INotificationRepository SMS methods, breaking compilation beyond the
intentionally-deferred central NotificationRepository.
Fix 1 (CS8620/CS8604 nullable EmailAddress projections, email-only paths):
- NotificationOutbox EmailNotificationDeliveryAdapter: filter non-null emails
- DeploymentManager ArtifactDeploymentService: filter non-null emails
- Transport EntitySerializer: filter non-null emails into NotificationRecipientDto
Fix 2 (CS0535): stub the four SMS-config methods on SiteRuntime
SiteNotificationRepository (central-only — NotSupportedException, matching the
existing 'Managed via artifact deployment from Central' write-path pattern).
Doc nits: reword NotificationRecipient private ctor and SmsConfiguration.AuthToken
comments.
The central ConfigurationDatabase.NotificationRepository compile break is left
as-is (S2 implements those four methods).
The high-sev advisory is on transitive native SQLitePCLRaw.lib.e_sqlite3 2.1.11
(via Microsoft.Data.Sqlite/EFCore.Sqlite). Microsoft.Data.Sqlite.Core 10.0.9 (latest
10.0.x) still references SQLitePCLRaw.core 2.1.11, so a supported-line bump doesn't clear
it; the only patched lib is the SQLitePCLRaw 3.x line, which is an unsupported/risky forced
override under a Data.Sqlite built for 2.1.x. Suppress ONLY this advisory (auditing stays on
for everything else) so the full solution AND the docker in-container restore build cleanly
without the blanket /p:NuGetAudit=false. No version/code change; runtime byte-identical.
Revisit when MS ships a 10.0.x referencing a patched bundle.
Live-run fixes: nested <details> made the summary selector ambiguous (strict-mode);
force every disclosure open via JS. Drop the brittle specific-line-text ('99') assert
(depends on CLI-seeded bodies) for a ≥1 add-hunk + ≥1 remove-hunk count check. (#230)
Pre-existing render-crash (introduced by eb4bce3e): a @* *@ comment between
attributes inside the site-health-trends <select> start tag rendered as an
invalid attribute name in a real browser (InvalidCharacterError on setAttribute),
tearing down the SignalR circuit whenever Site Health Trends renders. bUnit's
virtual DOM masked it; the live Playwright smoke (KpiTiles) caught it. Comment
moved outside the start tag.
- Root context menu now has tabindex/focus + Escape-key close (OnRootMenuKeyDown) mirroring the node menu
- Opening root menu calls _tree.DismissNodeContextMenu(); opening node menu fires OnNodeContextMenuOpened → DismissRootContextMenu so only one menu is ever visible
- Add FolderContextMenu_MoveUp_IsDisabled_OnFirstSibling and FolderContextMenu_MoveDown_IsDisabled_OnLastSibling bUnit tests
InjectAnalysisKind returns null on a null/empty trigger-config, so passing
--trigger-kind strict WITHOUT --trigger-config silently dropped the kind on
template script add/update and template alarm update. The CLI now detects that
combination (TriggerKindWillBeIgnored) and prints a clear warning to stderr,
then continues (warn-and-continue: the kind is advisory metadata, not a required
field, so the entity is still created — just without the requested analysis kind).
The --trigger-kind help text on all three commands now documents that it requires
--trigger-config, as does the CLI README.
This commit also carries the shared CLI command-builder file (Commands/TemplateCommands.cs)
and README, which the same builders edit for both #257 and the #54 flag additions —
the #54 message contracts/handler/UI/tests landed in the preceding commit.
- TriggerKindWillBeIgnored predicate + WarnIfTriggerKindIgnored stderr warning,
wired into script add/update and alarm update SetActions.
- Shared option descriptions document the --trigger-config requirement.
- Adds the #54 CLI flags (--min-time-between-runs, --execution-timeout-seconds) and
TryParseMinTimeBetweenRuns to the same builder file.
- Tests: TemplateTriggerKindIgnoredTests pins the warn predicate.
Expose TemplateScript.ExecutionTimeoutSeconds and MinTimeBetweenRuns (previously
settable only via Transport bundle import) on the CLI and Central UI authoring surfaces.
- Commons: add additive trailing optionals MinTimeBetweenRuns (TimeSpan?) and
ExecutionTimeoutSeconds (int?) to Add/UpdateTemplateScriptCommand.
- ManagementActor: thread both new fields into the built TemplateScript on add/update.
- CLI template script add/update: new --min-time-between-runs (duration: ms/s/min,
bare number = seconds, 0 = unset, mirroring DurationInput) and
--execution-timeout-seconds (int) flags, with client-side duration validation.
- Central UI TemplateEdit: add an Execution timeout input (seconds) on the script
trigger tab, mirroring the existing Min-time-between-runs control; null/0 = site default.
- Tests: TemplateScriptTimingTests pins the option surface + duration parsing; updated
the stale 'no UI control' comment on the TemplateService round-trip test.
Fold a List attribute's ElementDataType into the hashable projection so a
change to the element type (e.g. Int32 -> Double) with identical JSON-encoded
values is detected as a staleness/revision change. Inserted in alphabetical
position; null ElementDataType (scalars) is omitted by the canonical
serializer (WhenWritingNull), so scalar-only configs hash identically to
before. DiffService.AttributesEqual gains the same comparison to keep the
structured diff in parity with the staleness hash. Adds tests for differing
vs. equal ElementDataType (hash + diff) and the scalar no-op guard.
Change `mergeEffective` delegate in `ResolveWinners<T>` from `Func<string?, T, string?>`
to `Func<Winner<T>, T, string?>` so the alarm hook can inspect the existing winner's row.
Gate the per-setpoint merge in `ResolveAlarmWinners` on both sides being HiLo
(`existingWinner.Row.TriggerType == HiLo && derived.TriggerType == HiLo`), matching
`FlatteningService.ResolveInheritedAlarms` exactly. Base non-HiLo + derived HiLo now
falls through to whole-replace (derived config verbatim) — the same path the flattener
takes. Preview-only fix; the deploy path is unchanged.
Add test: `Resolve_BaseNonHiLo_DerivedHiLo_DerivedConfigWinsVerbatim` — asserts
resolver and flattener agree when base is ValueMatch and derived overrides to HiLo.
Joseph Doherty