OpenEnergyDashboard
Extend chart link to support from latest readings
#456 will allow date ranges in the URL. It is a use case that someone wants to show others the last day/week/month of data where it is always the current time frame. To support this, the chart link needs to give the user the option (button?) to use the same amount of time as the slider represents but make it so the recreated graph starts from the latest time reading. We want to allow the URL to do what it currently does in case the link is intended to reproduce exactly the dates currently show. It might be best if the user option only appears if the end time point is the latest time reading on the current graph. Note doing it this way will allow the user to show arbitrary time frames not just day/week/month. Having it fixed to the earliest time reading is not a normal use case and it seems very unlikely that earlier reading would be added later so the current URL is fine and we are not going to do that case.
There is now a design document to work on this issue. It should be used to get information on what to do.
Hello,
My team (@w-b-d @rianhassett @nickhitos) and I working on implementing the UI for #456 (allowing relative date ranges in ChartLinks), and I wanted to verify a detail regarding the current UI to ensure our enhancements remain cohesive with the existing design.
I'm modifying the "More Options" popup in the Graph view, specifically the ChartLinks section, to support the new changes for the “Keep Current” option. We've set up OED locally via Docker following the Developers First Steps Documentation. However, I noticed that the date range picker appears inside the More Options modal in my development environment UI, compared to the design doc image, where the date range picker appears in the sidebar, not in the modal. We’re unsure which layout we should work off of to modify the UI. I have attached reference images below comparing the UI in the design docs versus my development environment UI.
We believe the in-modal version is the current official layout in OED v1.0.0 and the design doc is outdated. Based on this, we are planning to
- Add a new checkbox (tentatively labeled “Keep Current”) under Chart Link in the More Options modal.
- Ensure this checkbox is only conditionally displayed when the chart's serverRange is unbounded on the right and bounded on the left as per the design document.
I have attached a mock UI design for the changes we plan to make to the “More Options” category for chart links.
To summarize, my final questions are:
- Which UI layout should we follow? Is the model integrated version the intended default or should we reflect the sidebar date range version?
- Do you recommend any visual design tweaks for our mock-up UI? [Link To Modify UI Design]
Thanks to @anntreasajojo , @w-b-d, @rianhassett & @nickhitos for your well thought out questions. I'll give my thoughts and let me know if anything is unclear.
You are correct that the date range picker was updated but I think that happened before the design doc. In the new version it can move from the more options modal to the main graphic page. It should do this when the range becomes bounded on either side (or both) and returns to the more options modal if it is changed to unbounded. Thus, it moves depending on the setting of the date range. The idea was that if it is unset then the user is not using it so it is in more options to avoid clutter on the main graphic pages. The new chartlink option is only available if the graphic is bounded on the left and unbounded on the right (as you note). Thus, the date range pick will be on the graphic page and not in the more options modal. This isn't too bad as the date range is normally visible (it might get hidden by the more options modal with unusual screen sizes but I'm unsure if one can make that happen). So, I think the date range picker will not be in the more options modal but that is not something you need to deal with nor change. Now, in your image the range is unbounded so that is why it is in the more options modal. Note the new chartlink option would not be available in this case.
As for your UI mock-up, I think it looks fine except the option should not be available for the unbounded date range shown. It could either be grayed out/uncheckable or removed. I'm not sure which is better but am leaning toward grayed out. OED does this for showing selected meters that cannot be graphed at this time and for incompatible menu items. I'm hoping this isn't too hard to do.
Hello,
Our team @anntreasajojo , @rianhassett & @nickhitos is continuing work on the chart link feature. We had a few questions regarding replicating the chart state using a chart link:
We're currently planning to add two URL parameters:
-
&keepCurrent=true — to reflect whether the "Keep current" checkbox is selected.
-
&timeSpan=
— to represent the number of days to go back from the current time (e.g., &timeSpan=1.75 for 1.75 days).
From our understanding, the current implementation uses the server range and the time the graph was created to compute the time shift each time the chart is loaded. We’re proposing that it may be cleaner and more efficient to compute the time span once during chart creation and store that directly in the URL via timeSpan.
Does that approach sound reasonable to you? We're happy to implement it as currently outlined in the design docs if preferred, just wanted to check in before moving forward.
The design mentions that this feature should be available only to admins. We originally assumed all OED users were admins within their orgs, but we now see the project supports admin-specific roles in the codebase. Would you like us to incorporate authentication checks for this feature, or should it remain available to all users?
Thanks!
@anntreasajojo , @rianhassett & @nickhitos Thank you for your thoughtful questions. My responses are below.
We had a few questions regarding replicating the chart state using a chart link:
We're currently planning to add two URL parameters:
* &keepCurrent=true — to reflect whether the "Keep current" checkbox is selected. * &timeSpan= — to represent the number of days to go back from the current time (e.g., &timeSpan=1.75 for 1.75 days).From our understanding, the current implementation uses the server range and the time the graph was created to compute the time shift each time the chart is loaded. We’re proposing that it may be cleaner and more efficient to compute the time span once during chart creation and store that directly in the URL via timeSpan.
Does that approach sound reasonable to you? We're happy to implement it as currently outlined in the design docs if preferred, just wanted to check in before moving forward.
If I understand correctly, the change is not in what the chart link will provide but in how it is computed. You want to get the timeSpan at creation time rather than doing it when the chart link is created. It is a trivial quantity of CPU time to do this so doing at graphing and paying the cost upfront (the value may never be used) is not important. So, I'm fine with this as this is a new feature so you won't break any existing chart links.
The design mentions that this feature should be available only to admins. We originally assumed all OED users were admins within their orgs, but we now see the project supports admin-specific roles in the codebase. Would you like us to incorporate authentication checks for this feature, or should it remain available to all users?
Admin is mentioned once and it does limit the usage. As you note, I see no reason why it should be limited. It isn't expensive or dangerous. As a matter of fact, I think it would be good to allow this. For example, suppose a non-admin is creating web pages and they want to embed OED graphics (an important reason OED has chart links). They should not need an admin to do one from current time. So, no controls on this and allow it for everyone.
Just as a side note, I think if an admin gives a chart link to a non-admin that asks for admin only information (such as graphing a meter that only the admin can see) then it won't fail but it will not reproduce the graphic. This is viewed as user error and we don't try to catch it.
Please let me know if anything is not clear, you have thoughts or would like help.