Frun1na opened a new pull request, #6792:
URL: https://github.com/apache/rocketmq-dashboard/pull/6792
### Which Issue(s) This PR Fixes
- Fixes #6791
### Brief Description
The deliveries filter bar could not express a one-sided time range. `GET
/api/system-alerts/deliveries/page` takes `from` and `to` as independent
optional parameters (`SystemAlertController.listDeliveriesPage:82-98`) and the
page's filter state is typed `{from?: string; to?: string}`, but the
`DatePicker.RangePicker` had no `allowEmpty` (Ant Design defaults it to
`[false, false]`, so the OK button stays disabled until both ends are set) and
its `onChange` wrote the filter only for a complete pair, assigning `{}` for
anything partial — clearing the applied range instead of applying the half the
operator picked. The picker now accepts one boundary (`allowEmpty={[true,
true]}`) and the handler maps each end independently, so "everything since X"
sends `from` and no `to` at all; this is the same treatment #6637 applied to
the system alerts page a few hours earlier. No behaviour changes for a complete
or cleared range.
### How Did You Test This Change?
```
$ ./wb test --tree worktrees/rocketmq-dashboard/deliveries-open-time-filter
✓ npx eslint src/pages/ops/__tests__/NotificationDeliveriesPage.test.tsx
src/pages/ops/notificationDeliveries.tsx
✓ npx prettier --check
src/pages/ops/__tests__/NotificationDeliveriesPage.test.tsx
src/pages/ops/notificationDeliveries.tsx
✓ npx vitest related --run
src/pages/ops/__tests__/NotificationDeliveriesPage.test.tsx
src/pages/ops/notificationDeliveries.tsx
✓ npx tsc -b
Test Files 2 passed (2)
Tests 18 passed (18)
```
The new test picks a single start day in the rendered picker (panel cell →
OK → blur) and asserts the request carries `from` and no `to` key.
The new test fails without the fix:
```
$ npx vitest run src/pages/ops/__tests__/NotificationDeliveriesPage.test.tsx
FAIL src/pages/ops/__tests__/NotificationDeliveriesPage.test.tsx >
NotificationDeliveriesPage > appliesASingleTimeBoundaryToTheDeliveryFilterTest
AssertionError: expected last "vi.fn()" call to have been called with [
ObjectContaining{…} ]
❯ src/pages/ops/__tests__/NotificationDeliveriesPage.test.tsx:207:39
expect(listAlertDeliveriesPage).toHaveBeenLastCalledWith(
Test Files 1 failed (1)
Tests 1 failed | 7 passed (8)
```
The assertion reads the argument of the last `listAlertDeliveriesPage` call:
with the old handler the partial pick is turned into `{}`, so the recorded call
has no `from` and the assertion flips to red — the picker can produce the
partial value (its calendar panel confirms it), the handler was what discarded
it.
### Other consumers
Two more range pickers in this console share the "two-sided only" shape over
endpoints with independent optional endpoints: the audit page's date filter
(`audit.tsx:498`, `/api/audit-logs` takes `startDate`/`endDate` independently)
and the resource timeline modal (`ResourceOperationTimelineModal.tsx:174`).
Both are date-only pickers — they have no time panel and no explicit confirm
step, so their partial-submit path differs from the one covered here and they
are deliberately left to a separate change; their filter builders already map a
single end correctly.
### Checklist
- [x] One coherent change; unrelated modifications are not bundled in
- [x] Commit subject follows Conventional Commits (`feat:` / `fix:` /
`refactor:` / `chore:` / `docs:` / `perf:`)
- [x] Tests added or updated for non-trivial changes, test methods named
`...Test`
- [ ] New UI text has both Chinese and English entries under `web/src/i18n/`
- [ ] Architecture constraints stay green (`mvn test` runs the ArchUnit
checks)
- [ ] New source files carry the ASF license header
- [ ] Documentation touched where behaviour changed (README / `docs/` /
in-app help)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
