-
Notifications
You must be signed in to change notification settings - Fork 11.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PublicDashboards: Support timezone on query API #68560
PublicDashboards: Support timezone on query API #68560
Conversation
public/app/features/dashboard/services/PublicDashboardDataSource.ts
Outdated
Show resolved
Hide resolved
Co-authored-by: Juan Cabanas <juan.cabanas@grafana.com>
…ce.ts Co-authored-by: Juan Cabanas <juan.cabanas@grafana.com>
type PublicDashboardQueryDTO struct { | ||
IntervalMs int64 | ||
MaxDataPoints int64 | ||
QueryCachingTTL int64 | ||
TimeRange TimeSettings | ||
TimeRange TimeRangeDTO |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@evictorero wonder why Location is added to TimeRangeDTO
? Think we should use standard TimeRange
struct rather than introducing public dashboard specific DTO. What's the issue with placing the Location
on PublicDashboardQueryDTO
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could move Location
to the upper level but I think it makes sense since it is related to the from
and to
.
Which standard TimeRange
struct are you referring to?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are talking about the TimeSettings
struct that I am removing right? That is a model struct, we created it to support saving the TimeSettings
data persisted for each public dashboard but we ended up not using it, there is a plan to remove it. On the other hand, we are also adding DTOs to separate the entities of the data transfer objects to remove coupling, that is why makes sense to have a DTO for the TimeRange
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@evictorero I'm talking about TimeRange strict available in github.com/grafana/grafana-plugin-sdk-go/backend . I'm not sure why we need to introduce yet another time range struct, while we have a standard one available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That TimeRange is different, the field types are Time
. We have strings because we are supporting relative time ranges (like now or now-1d) in the API (even when the frontend always sends the epoch in ms). We could change it to TimeRange
but we wouldn't support relative time ranges anymore.
What is this feature?
model
package toservice
yesterday
andlast 1 hour
Which issue(s) does this PR fix?:
Fixes #62903
Enterprise PR: https://github.com/grafana/grafana-enterprise/pull/5148
Special notes for your reviewer:
Please check that: