Compliance report does not always show properly filtered results
Summary
The Compliance Report does not always show all violations that should appear for the current day with the default date filters.
Interestingly, this appears to be a UI bug for only some users. After discussing on Slack with @rob.hunt, it was confirmed that some users correctly see all results for the given date range in the UI while others do not. Both users were able to see all the expected results when using the GraphQL API directly.
Of note, Rob is in the UK while Sam is in the US, so perhaps something related to timezones is at play.
Steps to reproduce
I confirmed this happens in my normal browser, a second browser, and a logged-in incognito session on the original browser.
I confirmed this result happens if I look at the Compliance Report on both the root group and in a child group.
This was all done on GitLab.com.
Example Project
What is the current bug behavior?
(All images were taken on 2022-07-13, so that day is considered "today.")
This image shows the Compliance Report with only 3 results, when there should be 6. This was reached by clicking the Compliance report
button on the sidebar. Note the URL and date filters selected. This same URL showed 6 results for Rob when he tried it.
This image shows the Compliance Report with 6 results, but the URL string was manually edited to be one day in the future.
This image shows a GraphQL returning all 6 results as expected.
What is the expected correct behavior?
The UI should be displaying all 6 results to include the current day's results.
Relevant logs and/or screenshots
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true
)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true
)(we will only investigate if the tests are passing)
Current workarounds
There are two possible options:
- Change your device's timezone to a UTC neutral (
UTC+0
) or UTC positive timezone (UTC+
) by either changing the system clock or using a browser extension to spoof it. - Change the URL's
mergedBefore
date to be the date for tomorrow. It won't be reflected in the filters but it does trick the date formatter into using the current date instead.
Implementation plan
frontend -
- Set
utc
property totrue
forformatDate()
usages - Add test to
utils_spec.js
to confirm that the timezone is now ignored as with the rest of the codebase
A quick patch for the utc
property change:
Index: ee/app/assets/javascripts/compliance_dashboard/utils.js
<+>UTF-8
===================================================================
diff --git a/ee/app/assets/javascripts/compliance_dashboard/utils.js b/ee/app/assets/javascripts/compliance_dashboard/utils.js
--- a/ee/app/assets/javascripts/compliance_dashboard/utils.js (revision Staged)
+++ b/ee/app/assets/javascripts/compliance_dashboard/utils.js (date 1657726262123)
@@ -13,8 +13,8 @@
export const parseViolationsQueryFilter = ({ mergedBefore, mergedAfter, projectIds }) => ({
projectIds: projectIds ? convertProjectIdsToGraphQl(projectIds) : [],
- mergedBefore: formatDate(mergedBefore, ISO_SHORT_FORMAT),
- mergedAfter: formatDate(mergedAfter, ISO_SHORT_FORMAT),
+ mergedBefore: formatDate(mergedBefore, ISO_SHORT_FORMAT, true),
+ mergedAfter: formatDate(mergedAfter, ISO_SHORT_FORMAT, true),
});
export const buildDefaultFilterParams = (queryString) => ({