Fix annotation icon placement for "lastX"/"previousX" ranges #21862
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description:
When viewing an evolution graph, existing annotations are fetched using
Annotations\Controller::getAnnotationCountForDates()
, internal API call is usingAnnotations\API::getAnnotationCountForDates
, to display as icons below the graph:If your current user is viewing reports using either
previous30
orlast30
ranges (can be set in "Personal Settings"), the annotation icons are misplaced by one day:This happens because of the special treatment of the aforementioned ranges in
Annotations::getDateRangeForPeriod()
. Availalbe dates for annotations are usingDate::factory('now')
, internally only usingsubPeriod()
in this case, not discarding the current time information.Later in the process, during
Annotations\AnnotationsList::search()
, a timestamp comparison is used to select the day an annotation is displayed for. As all annotations are stored without any time information,2024-01-02
with be matched by, for example, the incorrect2024-01-01 12:00:00 < 2024-01-02 11:59:59
range, instead of next days2024-01-02 00:00:00 < 2024-01-02 23:59:59
range, and then displayed at the wrong position.Discarding the time information after range parsing should fix that problem.
Fixes #21837
Review