[OpenNMS/opennms] 68f514: NMS-20280: Address PR review findings on TimeControls

  Branch: refs/heads/jira/NMS-20280-onms-timepicker
  Home:   https://github.com/OpenNMS/opennms
  Commit: 68f514213a99c9abd93666e917227a8b6fa71375
      https://github.com/OpenNMS/opennms/commit/68f514213a99c9abd93666e917227a8b6fa71375
  Author: Scott Theleman <[email protected]>
  Date:   2026-09-01 (Tue, 01 Sep 2026)

  Changed paths:
    M ui/packages/onms-ui/README.md
    M ui/packages/onms-ui/src/components/OnmsDatePicker.vue
    M ui/src/components/Common/TimeControls.vue
    M ui/tests/components/Common/TimeControls.test.ts
    M ui/tests/onms-ui/OnmsDatePicker.test.ts

  Log Message:
  -----------
  NMS-20280: Address PR review findings on TimeControls

Accessible name of the range button (finding 1): aria-labelledby REPLACES an
element's content as its accessible name, so pointing it at the label span
alone renamed the button from "Last day" to "Time Range:" -- dropping the
selected range, the only changing information the button carries. The button
now carries its own id and is labelled by "<label id> <own id>", giving
"Time Range: Last day".

Range validity (finding 2): the :minDate/:maxDate cross-wiring is a UI
affordance, not a correctness guarantee. PrimeVue's isSelectable() compares
year/month/day only, and the typed-input path (isValidSelection, with
manualInput defaulting to true) goes through it -- so typing a later time on
the boundary day into Start is accepted unclamped and inverts the range, which
then reads as a negative difference and mislabels the window as "minutes". A
calendar click does clamp at full granularity, but clamping Start to maxDate
lands it exactly on End, which is a zero-width window. Both slipped past the
old null-only check. Apply is now disabled unless end > start, the End field
explains why, and applyCustomTime re-checks rather than trusting the button
state.

Label association (finding 4): OnmsDatePicker gains an inputId prop, which
PrimeVue puts on the rendered <input> (a plain id would fall through to the
wrapper, out of a label's reach), matching what OnmsSelect / OnmsInputNumber
and the other input wrappers already declare. The Start and End FormFields
pass a matching `for`, so their labels are associated for the first time.

Overlay-visibility window (finding 3): confirmed -- PrimeVue emits `show` from
the overlay's onEnter hook but binds its document dismisser in onAfterEnter, so
during the enter transition a picker reports itself open while nothing will
dismiss it. Left as-is and documented in the code: a press in that window makes
the preset click a no-op rather than a wrong action, and the next click behaves
normally. Suppressing only when the picker actually closed would restore the
original bug inside that same window, and PrimeVue exposes no way to dismiss
the overlay ourselves (onBlur does not close it; overlayVisible is internal).



To unsubscribe from these emails, change your notification settings at https://github.com/OpenNMS/opennms/settings/notifications


_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/wiki/index.php?page=MailingListFaq
opennms-cvs mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-cvs