Limit Productivity Analytics date filtering
What does this MR do?
It introduces start date limit for Productivity Analytics so UI can block users to get further in past than PA was introduced.
Screenshots
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation created/updated or follow-up review issue created -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Performance and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team
Data migration info
Query plan for data migration (tested via #database-lab):
explain SELECT "merge_request_metrics"."merged_at" FROM "merge_request_metrics" WHERE (merged_at > '2019-09-01') AND "merge_request_metrics"."commits_count" IS NOT NULL ORDER BY "merge_request_metrics"."merged_at" ASC LIMIT 1
Limit (cost=0.43..0.47 rows=1 width=8) (actual time=0.059..0.060 rows=1 loops=1)
Buffers: shared hit=4
-> Index Only Scan using tmp_migration_index on public.merge_request_metrics (cost=0.43..8293.56 rows=207686 width=8) (actual time=0.057..0.057 rows=1 loops=1)
Heap Fetches: 0
Buffers: shared hit=4
Cost: 8293.56
Time: 1.133 ms
- planning: 1.043 ms
- execution: 0.090 ms
Shared buffers:
- hits: 4 (~32.00 KiB) from the buffer pool
- reads: 0 from the OS file cache, including disk I/O
- dirtied: 0
- writes: 0
Closes #32052 (closed)
Edited by Pavel Shutsin