Follow-up cleanup after #1530 / PR #1533 ships and Daytime emails have been running in production for a while.
The implementation deliberately accepted some asymmetry to keep the migration small and rollback-safe. Once we're confident in the new behavior, the asymmetry can be paid down.
1. Rename `notifications.orders.sendingtimepolicy` → `smssendingtimepolicy`
Today the orders table has:
- `sendingtimepolicy` (used for SMS only)
- `emailsendingtimepolicy` (added in v0.80)
The naming is confusing because `sendingtimepolicy` looks generic but is actually SMS-specific. The original issue (#1530) explicitly deferred this rename:
The existing `notifications.orders.sendingtimepolicy` column (used by SMS) is intentionally not renamed to `smssendingtimepolicy`. Renaming would complicate rollback and is outside this issue's scope. The naming asymmetry is accepted.
The rename touches:
- A new migration that renames the column (or adds the new name + dual-writes for a deploy or two, then drops the old name).
- `claim_anytime_sms_batch` and `claim_daytime_sms_batch` (filter clause).
- `insertorder` overloads in `FunctionsAndProcedures/insertorder.sql`.
- `OrderRepository.InsertOrder` parameter ordering and the `_insertOrderSql` constant.
- Any usage in tests / status feed queries that touch the column.
2. Consider `record SendingTimePolicies(SendingTimePolicy? Sms, SendingTimePolicy? Email)` on NotificationOrder
`NotificationOrder` currently exposes two parallel properties:
```csharp
public SendingTimePolicy? SendingTimePolicy { get; internal set; } // SMS
public SendingTimePolicy? EmailSendingTimePolicy { get; internal set; }
```
When an order has both SMS and email recipients with different policies this is workable but easy to misread. The original issue noted:
A `record SendingTimePolicies(SendingTimePolicy? Sms, SendingTimePolicy? Email)` wrapper could be cleaner — left to PR review rather than pre-decided.
Whether this is actually cleaner depends on how the model is used downstream — worth revisiting after some time on the new structure.
Out of scope
Anything that changes runtime behavior. This issue is purely about reducing asymmetry/inconsistency once we know the design is stable.
Acceptance
Follow-up cleanup after #1530 / PR #1533 ships and Daytime emails have been running in production for a while.
The implementation deliberately accepted some asymmetry to keep the migration small and rollback-safe. Once we're confident in the new behavior, the asymmetry can be paid down.
1. Rename `notifications.orders.sendingtimepolicy` → `smssendingtimepolicy`
Today the orders table has:
The naming is confusing because `sendingtimepolicy` looks generic but is actually SMS-specific. The original issue (#1530) explicitly deferred this rename:
The rename touches:
2. Consider `record SendingTimePolicies(SendingTimePolicy? Sms, SendingTimePolicy? Email)` on NotificationOrder
`NotificationOrder` currently exposes two parallel properties:
```csharp
public SendingTimePolicy? SendingTimePolicy { get; internal set; } // SMS
public SendingTimePolicy? EmailSendingTimePolicy { get; internal set; }
```
When an order has both SMS and email recipients with different policies this is workable but easy to misread. The original issue noted:
Whether this is actually cleaner depends on how the model is used downstream — worth revisiting after some time on the new structure.
Out of scope
Anything that changes runtime behavior. This issue is purely about reducing asymmetry/inconsistency once we know the design is stable.
Acceptance