Fix missing access checks on issue lookup using IssuableFinder
Split from !2024 to partially solve https://gitlab.com/gitlab-org/gitlab-ce/issues/23867⚠️ - Potentially untested
💣 - No test coverage
🚥 - Test coverage of some sort exists (a test failed when error raised)
🚦 - Test coverage of return value (a test failed when nil used)
✅ - Permissions check tested
- [x] ✅ app/controllers/projects/branches_controller.rb:39
- `before_action :authorize_push_code!` helpes limit/prevent exploitation. Always checks for reporter access so fine with
confidential issues, issues only visible to team, etc.
- [x] 🚥 app/models/cycle_analytics/summary.rb:9 [`.count`]
- [x] ✅ app/controllers/projects/todos_controller.rb:19
- [x] Potential double render in app/controllers/projects/todos_controller.rb
- https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#cedccb227af9bfdf88802767cb58d43c2b977439_24_24
See merge request !2030
- The commit count was capped at 10, due to
`Gitlab::Git::Repository#log` enforcing a limit, with the default set
to 10.
- Reimplement a small portion of this `log` function to get just the
data we need.
- Don't use `TableReferences` - using `.arel_table` is shorter!
- Move some database-related code to `Gitlab::Database`
- Remove the `MergeRequest#issues_closed` and
`Issue#closed_by_merge_requests` associations. They were either
shadowing or were too similar to existing methods. They are not being
used anywhere, so it's better to remove them to reduce confusion.
- Use Rails 3-style validations
- Index for `MergeRequest::Metrics#first_deployed_to_production_at`
- Only include `CycleAnalyticsHelpers::TestGeneration` for specs that
need it.
- Other minor refactorings.
1. Move the test generation to `CycleAnalyticsHelpers::TestGeneration`
2. Move all helper methods (previously placed in each individual spec
file) to `CycleAnalyticsHelpers`
Add a `before_end_fn` option to the code that generates cycle analytics
specs. `before_end_fn` is called before the end conditions are. Used for
data setup that needs to be called after the start conditions and before
the end conditions.
Remove overlap from the "start + end" durations in the happy test
case. For the `staging` phase, the end time is the _first_ deployment
that happens after the MR merge.
If we have 5 MRs where the `start_time`s (merge time) are the
same, and all the `end_time`s (deploy to production) a few days from
now, only the earliest deploy will get picked up, because that
consitutes a deploy for _all_ the MRs.
We fix this by removing overlap. Every `start_time` is now generated to
be _after_ the preceding `end_time`.
1. Generalise the specs that will be common across all cycle analytics
phases.
2. Rewrite specs `issue` and `plan` to use this abstracted testing
strategy.
3. Specs that are specific to a given phase, or unwieldy to test in an
abstracted manner, are added to each phase's spec.
1. Supported date ranges are 30 / 90 days ago. The default is 90 days
ago.
2. All issues created before "x days ago" are filtered out, even if they
have other related data (test runs, merge requests) within the filter
range.
