Repository navigation
Date/recent time-range picker and a bounded-by-default All Messages view - #3106
Conversation
ramonsmits
changed the title
161f469 to
fcebabe
Compare
johnsimons
left a comment
johnsimons
left a comment
There was a problem hiding this comment.
@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
- ....
|
I haven't had time to look at the code yet @ramonsmits, but a few things to consider based on the screenshots.
|
@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. |
exactly this, its currently the combination.
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.
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 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. |
fcebabe to
c55fca7
Compare
c55fca7 to
376729b
Compare
ramonsmits
changed the title
376729b to
fe6c289
Compare
fe6c289 to
e9a04e1
Compare
johnsimons
left a comment
johnsimons
left a comment
There was a problem hiding this comment.
I still think we need to have a calendar picker for dates, same as what Grafana provides
| <button v-for="preset in rangePresets" :key="preset.label" type="button" class="quick-item" @click="applyPreset(preset.from, preset.to)"> | ||
| {{ preset.label }} | ||
| </button> |
There was a problem hiding this comment.
These are styled as links. Have you considered just making these a elements instead
There was a problem hiding this comment.
No, but IMHO button is the right type, it isn't a link.
|
You can delete @/components/audit/DatePickerRange.vue" and also remove the @vuepic/vue-datepicker npm package |
Addressed comment by adding a date picker similar to grafana
77b8c73 to
931f0f6
Compare
931f0f6 to
3327709
Compare
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, the live expression ("now-90m"; a range ending now is
what "last N" means) or "start to end" for an absolute range; the
resolved window in UTC and local time is its tooltip.
The editor is laid out like Grafana's: the absolute range on the left
with From and To on their own rows, the quick ranges listed on the
right. 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, Z forces UTC,
explicit offsets are honored) and pasted ISO 8601 intervals split
across both bounds; a hint under the fields says so. A calendar button
per bound opens the browser's own date picker (day only, so it closes
on the day click) and writes the day into the field while keeping the
time the field already says.
A timed-out query offers the two next-narrower presets as one-click
buttons (query cost grows with the window), and a query with no time
filter at all is called out as an unbounded scan of the whole store.
A per-browser default decides what the view opens on; the 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.
The popup is not a Popover API popover: a popover sits in the top
layer, centred, and anchoring it under the chip needs CSS anchor
positioning, which Firefox ESR does not have yet.
DatePickerRange.vue lost its only user when the Sent chip took over the filters panel; nothing else imported it or @vuepic/vue-datepicker, so both go, along with the package's stylesheet from the bundle.
3327709 to
81ee053
Compare
4 participants
Stacked on:
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)time_sent)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 presetsReview feedback applied:
nowis shown as its start only (now-90m), since "last N" is what it meansDatePickerRange.vueand@vuepic/vue-datepickerhad no remaining users and are goneStill open from the review: the popover API for the popup and the presets as links. The wider From field no longer cuts the placeholder off.
The rest of the original scope of this PR moved into separate stacked PRs (see the stack list in the follow-up PRs).