UI: remove initial date from client counts#27816
Conversation
|
CI Results: |
|
Build Results: |
| if (!isNaN(millis)) { | ||
| timestamp = fromUnixTime(millis).toISOString(); | ||
| } | ||
| // fallback to activity timestamp only if there was no query param |
There was a problem hiding this comment.
thank you for these comments!
| startTimestamp: this.paramOrResponseTimestamp(params?.start_time, activity?.byMonth[0]?.timestamp), | ||
| endTimestamp: this.paramOrResponseTimestamp(params?.end_time, activity?.endTime), |
There was a problem hiding this comment.
So the new functionality is these params correspond to the range of data requested and the activity above (line 93) has start and end time parameters that correspond to the start_time and end_time from the /activity response?
I'm just thinking through the logic we have that lets users know "You have requested [start date] we only have data from [start of data]"
paramOrResponseTimestamp is helpfully named, I wonder if a comment above this function would help clarify the difference between selecting the first month timestamp vs the start/end params on the actual activity response 🤔
There was a problem hiding this comment.
Good idea, I can definitely add a comment with a description about what this does!
If query params were used, we want to set the start and end timestamps to match those, as you said, because the API start time matches the first month that data was returned. I found that if I just relied on the API timestamp responses, the message about only having data from [start of data] never showed up, because the timestamps matched. So, instead I had to default to the first month's timestamp if no query param was used, to ensure that the discrepancy message displayed when the data wasn't available for all months.
hellobontempo
left a comment
There was a problem hiding this comment.
Great work on this ⭐ ⭐ ⭐ ⭐ ! 🚢
Description
This PR updates the client count dashboard so that it sends the
/activityrequest without start & end date parameters by default, which as of 1.18 will return the billing range by default. For the community edition, we will continue to not make the API call until there is an explicit date range set by the user, at which point query params are added to the URL.CE experience

For community users, they must manually set a date range in order to see data. On dashboard page load, we do not initiate a request to the
/activityendpoint until the user has adjusted the date range.We also don't allow the user to unset the query params for the date range:

Ent experience

In Enterprise, we do make a call to the
/activityendpoint on page load, now without any query params so the backend will calculate the billing dates to use and return that data. In addition, the date range is pre-populated with the timestamp of the first month returned, and the end date from the response itself.