feat(sms): make FromNumber optional — support Twilio Messaging-Service-only configs (UI-Med-2)
Code-review finding UI-Med-2: the design doc + delivery adapter treat FromNumber and MessagingServiceSid as either-or, but the entity ctor, EF schema, UI and CLI all hard- required FromNumber — so a Messaging-Service-only Twilio config (a normal production setup) could not be created. Bring the implementation into line with the spec: - Commons: SmsConfiguration.FromNumber -> string? (ctor fromNumber optional); UpdateSmsConfigCommand.FromNumber -> string?. - ConfigurationDatabase: FromNumber.IsRequired(false) + migration SmsFromNumberOptional (ALTER COLUMN nullable, idempotent; Down backfills '' — harmless, MsgSid keeps it deliverable) + regenerated model snapshot. - Transport: SmsConfigDto.FromNumber -> string? (round-trips a Messaging-Service-only config). - CentralUI: form validation requires AccountSid + at-least-one-of(FromNumber, MsgSid); nullable create/edit paths; From-number help text. - CLI: --from-number no longer Required; BuildUpdateSmsConfigCommand validates the either-or. - Adapter: From branch null-forgiving (guarded by the existing incomplete-config check). Tests: ManagementActor MsgSid-only persists null FromNumber; CLI MsgSid-only builds + neither-throws + contract (--from-number not Required); CentralUI MsgSid-only save.
This commit is contained in:
+3
-1
@@ -211,7 +211,9 @@ public sealed class SmsNotificationDeliveryAdapter : INotificationDeliveryAdapte
|
||||
}
|
||||
else
|
||||
{
|
||||
form.Add(new KeyValuePair<string, string>("From", smsConfig.FromNumber));
|
||||
// The line 113 guard guarantees a non-null FromNumber whenever there is no
|
||||
// MessagingServiceSid, so this branch never sends a null From.
|
||||
form.Add(new KeyValuePair<string, string>("From", smsConfig.FromNumber!));
|
||||
}
|
||||
|
||||
using var request = new HttpRequestMessage(HttpMethod.Post, requestUri)
|
||||
|
||||
Reference in New Issue
Block a user