Date/recent time-range picker and a bounded-by-default All Messages view by ramonsmits · Pull Request #3106 · Particular/ServicePulse

ramonsmits · 2026-09-03T16:48:05Z

Stacked on:

Keep All Messages usable during slow queries #3105

Second PR in the audit query series. Makes the All Messages view bounded by default and gives users control over expensive queries. On a ~158M-message store the unbounded default query took 15–17 s; bounded to a recent window it returns in 1–2 s.

Time range picker (`Sent:` chip)

Replaces the calendar-only date range control with a compact chip in the query bar labeled for what it filters (time_sent)
Bounds are text expressions: relative (now-6h, now-1d/d) or tolerant RFC 3339 (2026-08-31Z, offsets honored); a pasted ISO 8601 interval splits across both bounds. Timestamps are frequently copied from logs, which is why typing/pasting is first-class next to the Grafana-style presets
Expressions stay in the URL and resolve at query time, so shared links and auto-refresh windows keep sliding
Default is the last 6 hours; a different default can be saved per browser, or the range cleared entirely
A timed-out query offers the next-narrower presets as one-click buttons; a query with no time filter is called out as an unbounded scan

Review feedback applied: the "UTC … · local … · live" diagnostics line under the editor is gone. The editor only gives feedback when the draft cannot be applied; the resolved window remains as the chip tooltip.

The rest of the original scope of this PR moved into separate stacked PRs (see the stack list in the follow-up PRs).

johnsimons

@ramonsmits there is a lot going on here.
Would it be possible to split this PR into more manageable slices.
Example:

The new date range picker on its own
The history for the search
The reorganizing of the UI
....

johnsimons · 2026-09-07T07:58:24Z

I haven't had time to look at the code yet @ramonsmits, but a few things to consider based on the screenshots.

Could the "history" be built into the text field, so, in other words, when the user's focus is on the search text field, we have a floating panel below it that shows them the history options? I kind of understand why you want to make it a separate dropdown because it is the history for the whole combined filters, but its location at the moment feels associated with the text field.
The date ranges using now-2d, I do like it. It reminds me of Grafana; it may be useful to look at the Grafana UI and get some ideas from it.
I am not sold on this text, it is hard to figure out what it says
I think local vs utc times should be app wide not specific per screen

ramonsmits · 2026-09-07T09:06:56Z

@ramonsmits there is a lot going on here. Would it be possible to split this PR into more manageable slices. Example:

The new date range picker on its own

The history for the search

The reorganizing of the UI

....

@johnsimons I understand, I'll check if I can split these.. thing is.. I already have 3 stacked PRs and this means even more stacked ones many share the same base.

ramonsmits · 2026-09-07T09:20:41Z

Could the "history" be built into the text field, so, in other words, when the user's focus is on the search text field, we have a floating panel below it that shows them the history options? I kind of understand why you want to make it a separate dropdown because it is the history for the whole combined filters, but its location at the moment feels associated with the text field.

exactly this, its currently the combination.

The date ranges using now-2d, I do like it. It reminds me of Grafana; it may be useful to look at the Grafana UI and get some ideas from it.

Guess what the inspiration was ;-)

The difference was that I wanted a way to be able to paste timestamps as these are frequently copy/pasted from logs etc.

Do you miss anything critical? Already the ability to select options and also ability to enter timestamps with zone offsets or UTC is supported.

I do like the refresh style... maybe I can tweak that a bit more.

I am not sold on this text, it is hard to figure out what it says

TBH that is more for diagnostics to validate if the conversion from text input to url output was happening correctly. I'll update it to only show the resolved timezone offset (utc, local or specific offset)

I think local vs utc times should be app wide not specific per screen

I partially agree, there might be value in having user (or maybe only local) specific settings but in the primary use case for this screen is diagnostics based on data provided from support inquiries where a timestamp is likely not always fixed.

My assumption is that a user wants by default to show time based on their system settings on all screens. However, this screen specifically is search related to diagnostics (local) but engineers frequently want to see timestamps in UTC too for comparing as that is what servers usually are set to or in which timestamps are actually stored.

Replaces the calendar-only date range control with a compact chip in the query bar — 'Sent: Last 6 hours ▾' — labeled for what it filters (time_sent) and styled like the neighboring dropdowns. The chip shows the preset name, live expressions, or a compact resolved range; the full dual-zone RFC 3339 detail is its tooltip. Clicking opens the editor: each bound accepts relative expressions that stay live (now, now-6h, now/d, now-1d/d), tolerant RFC 3339 (T or space separator, seconds optional, zone optional; zone-less is local, 2026-08-31Z forces UTC, explicit offsets are honored) and pasted ISO 8601 intervals split across both bounds, with a live echo showing the resolved range in UTC and local time. Quick presets and a per-browser default complete it: 'Save current range as default' (confirmed, with reset) decides what the view opens on — factory default is the last 6 hours, so opening the view never scans the whole audit store. Ranges travel in the URL as expressions, so shared links re-evaluate and live ranges slide with auto-refresh.

Query cost grows with the time window, so the error banner now explains that and offers the two next-narrower presets as buttons (widest first). A query with no time filter at all gets called out explicitly — an unbounded scan of the whole audit store is the most likely reason it timed out — with the widest bounded presets as the escape hatch.

The "UTC … · local … · live" line under the range editor was a development aid to check the expression-to-URL conversion and was hard to read. It is gone; the editor only shows feedback when the draft cannot be applied. The resolved window (UTC and local) stays available as the tooltip of the collapsed chip.

johnsimons

I still think we need to have a calendar picker for dates, same as what Grafana provides

johnsimons · 2026-09-08T06:26:33Z

+async function toggleOpen() {
+  open.value = !open.value;
+  if (open.value) {
+    // Discard unapplied edits from a previous visit
+    fromText.value = timeRangeFrom.value;
+    toText.value = timeRangeTo.value;
+    await nextTick();
+    fromInput.value?.focus();
+  }
+}
+
+function onOutsidePointer(event: PointerEvent) {
+  if (open.value && root.value && !root.value.contains(event.target as Node)) open.value = false;
+}
+function onKeydown(event: KeyboardEvent) {
+  if (event.key === "Escape") open.value = false;
+}
+onMounted(() => document.addEventListener("pointerdown", onOutsidePointer));
+onBeforeUnmount(() => document.removeEventListener("pointerdown", onOutsidePointer));


A lot of this code can be removed if you use the popover api, it has all this build into it 😉

johnsimons · 2026-09-08T06:27:28Z

+            @keydown.enter="apply"
+            @paste="onPaste"
+          />
+          <span class="arrow" aria-hidden="true">→</span>


This is my preference, but have you considered using the word "to" instead of an arrow?

johnsimons · 2026-09-08T06:30:20Z

+        <button v-for="preset in rangePresets" :key="preset.label" type="button" class="quick-item" @click="applyPreset(preset.from, preset.to)">
+          {{ preset.label }}
+        </button>


These are styled as links. Have you considered just making these a elements instead

johnsimons · 2026-09-08T06:34:35Z

+            spellcheck="false"
+            autocomplete="off"
+            aria-label="Time range start"
+            placeholder="now-6h or 2026-09-01 08:00Z"


This is not visible in its entirety

johnsimons · 2026-09-08T06:48:33Z

You can delete @/components/audit/DatePickerRange.vue" and also remove the @vuepic/vue-datepicker npm package

internalautomation Bot assigned ramonsmits Sep 3, 2026

ramonsmits changed the title ~~Super date picker and a bounded-by-default All Messages view~~ New date/recent picker and a bounded-by-default All Messages view Sep 3, 2026

ramonsmits requested a review from mauroservienti September 3, 2026 16:56

ramonsmits added the Improvement Improvement label Sep 3, 2026

ramonsmits added this to the 2.11.0 milestone Sep 3, 2026

ramonsmits mentioned this pull request Sep 4, 2026

Surface incomplete scatter-gather results and server query timeouts #3107

Open

ramonsmits force-pushed the ramon/audit-super-date-picker branch from 161f469 to fcebabe Compare September 4, 2026 21:58

jpalac modified the milestones: 2.11.0, 2.12.0 Sep 6, 2026

johnsimons requested changes Sep 7, 2026

View reviewed changes

ramonsmits force-pushed the ramon/audit-super-date-picker branch from fcebabe to c55fca7 Compare September 7, 2026 10:13

ramonsmits force-pushed the ramon/audit-super-date-picker branch from c55fca7 to 376729b Compare September 7, 2026 10:31

ramonsmits changed the title ~~New date/recent picker and a bounded-by-default All Messages view~~ Date/recent time-range picker and a bounded-by-default All Messages view Sep 7, 2026

ramonsmits requested a review from johnsimons September 7, 2026 10:35

ramonsmits mentioned this pull request Sep 7, 2026

Animate rows that arrived since the previous refresh in All Messages #3114

Open

ramonsmits force-pushed the ramon/audit-super-date-picker branch from 376729b to fe6c289 Compare September 7, 2026 12:40

ramonsmits added 3 commits September 7, 2026 17:43

ramonsmits force-pushed the ramon/audit-super-date-picker branch from fe6c289 to e9a04e1 Compare September 7, 2026 15:46

johnsimons requested changes Sep 8, 2026

View reviewed changes

johnsimons reviewed Sep 8, 2026

View reviewed changes

Navigation Menu

Uh oh!

Date/recent time-range picker and a bounded-by-default All Messages view - #3106

Date/recent time-range picker and a bounded-by-default All Messages view#3106
ramonsmits wants to merge 3 commits into
ramon/audit-query-uxfrom
ramon/audit-super-date-picker

ramonsmits commented Sep 3, 2026 •

edited

Loading

Uh oh!

johnsimons left a comment

Uh oh!

johnsimons commented Sep 7, 2026

Uh oh!

ramonsmits commented Sep 7, 2026

Uh oh!

ramonsmits commented Sep 7, 2026

Uh oh!

johnsimons left a comment

Uh oh!

johnsimons Sep 8, 2026

Uh oh!

johnsimons Sep 8, 2026

Uh oh!

johnsimons Sep 8, 2026

Uh oh!

johnsimons Sep 8, 2026

Uh oh!

johnsimons commented Sep 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

ramonsmits commented Sep 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Time range picker (Sent: chip)

Uh oh!

johnsimons left a comment

Choose a reason for hiding this comment

Uh oh!

johnsimons commented Sep 7, 2026

Uh oh!

ramonsmits commented Sep 7, 2026

Uh oh!

ramonsmits commented Sep 7, 2026

Uh oh!

johnsimons left a comment

Choose a reason for hiding this comment

Uh oh!

johnsimons Sep 8, 2026

Choose a reason for hiding this comment

Uh oh!

johnsimons Sep 8, 2026

Choose a reason for hiding this comment

Uh oh!

johnsimons Sep 8, 2026

Choose a reason for hiding this comment

Uh oh!

johnsimons Sep 8, 2026

Choose a reason for hiding this comment

Uh oh!

johnsimons commented Sep 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

ramonsmits commented Sep 3, 2026 •

edited

Loading

Time range picker (`Sent:` chip)