Add filters to Platform Usage report #687
Comments
labradford
changed the title
|
QA - Platform report is properly filtering |
Pitt QA concerns:begin_date / end_date limitsWhen limiting the begin_date and end_date, metrics from outside of the range are still reported: Expected output is: begin_date after end_dateWhen the begin_date filter is after the end_date filter, a 3020 Exception is expected: Expected output: Are general Exception responses to be considered for another issue? I see that various invalid inputs return JSON with errors, but not formatted as exceptions. E.g.: |
Pitt QA concernsReport filters in the headerSee also: Here, the |
Prior to this commit, the inner logic that built the array of data was not using the begin and end date filter. With this commit, those sub-queries are all limiting the queries to those that are within the given date range. Related to: - #687
|
@ctgraham both of your comments above have been addressed. ready for review. |
|
Confirming that the date range bounding and report filters look good. I did try a query placing the month before the year as: This returned an Exception 3031, but probably should have been an Exception 3020. I also tried overspecifying the date as year-month-day: This returned the non-intuitive message of: A query for start-of-month-July and end-of-month-July return identical data, so I presume the day of month is currently ignored. Finally, will the inclusion of Search_Investigations be removed from this report when filtered to Total_Item_Investigations per: |
what messaging are you imagining instead?
correct.
yes! (except that Total_Item_Investigations isn't a valid filter value. I believe you mean Total_Item_Requests. ref: this link) |
|
If the user's input is valid, but discarded/amended for a successful response (like substituting a begin_date of "2023-05-01" for "2023-05-30"), an informational Exception 0 should be included in the Report_Header which describes the successful substitution. If the user's input is valid, but discarded/amended for a failed response, the resulting Exception should describe that, e.g.: |
`Searches_Platform` is a valid metric_type filter according to https://countermetrics.stoplight.io/docs/counter-sushi-api/xggfvq5by3gx0-pr-p1-report-filters. before this commit we were always returning `Searches_Platform`, despite whether a `metric_type` filter was being used. with this commit, we only return `Searches_Platform` if the `metric_type` param includes it, or is not being passed at all. ref: #687 (comment)
This is necessary because calling `to_date` on a string in 'MM-YYYY'
format will assume that 'MM' is the day, and will set the current month
as 'MM' instead.
params.fetch(:begin_date) => "06-2023"
params.fetch(:begin_date).to_date => Wed, 06 Sep 2023
We are also still allowing for dates to use MM-DD-YYYY format.
'2023-06-10'.match(/(^\d{4}-\d{2}$)|(^\d{4}-\d{2}-\d{2}$)/)
=> #<MatchData "2023-06-10" 1:nil 2:"2023-06-10">
'2023-06'.match(/(^\d{4}-\d{2}$)|(^\d{4}-\d{2}-\d{2}$)/)
=> #<MatchData "2023-06" 1:"2023-06" 2:nil>
'06-2023'.match(/(^\d{4}-\d{2}$)|(^\d{4}-\d{2}-\d{2}$)/)
=> nil
ref: #687 (comment)
exception 0 is a special case, as it represents info or debugging messages. when the query is successful, despite the exception, the exception is to be returned as part of the report header. ref: https://countermetrics.stoplight.io/docs/counter-sushi-api/jmelferytrixm-exception-0 ref: #687 (comment)
this is ready for review.
this is ready for review.
giving a date in |
|
Looks good. |
Story
Platform Usage Reports should be able to receive filter params for the following:
not currently supported in this implementation because we do not have the historical data to support
Acceptance Criteria
Screenshots / Video
Testing Instructions and Sample Files
Notes
The text was updated successfully, but these errors were encountered: