An error occurred fetching the project authors.
- 05 Oct, 2018 1 commit
-
-
Sean McGivern authored
We don't think this is needed any more - see https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21521, and https://gitlab.com/gitlab-org/gitlab-ce/issues/52271 for removing the flag.
-
- 03 Oct, 2018 1 commit
-
-
Jacopo authored
In GET `api/v4/projects/:id/issues` the user can filter issues that have an assigned milestone through the parameter `milestone=Any+Milestone`.
-
- 01 Oct, 2018 2 commits
-
-
Eva Kadlecová authored
-
Jarka Košanová authored
-
- 27 Sep, 2018 1 commit
-
-
Jarka Košanová authored
- add by_state filter to the epics finder - support count by states
-
- 11 Sep, 2018 3 commits
-
-
gfyoung authored
Partially addresses #47424.
-
Yorick Peterse authored
This whitelists all existing offenses for the various CodeReuse cops, of which most are triggered by the CodeReuse/ActiveRecord cop.
-
Yorick Peterse authored
This whitelists all existing offenses for the various CodeReuse cops, of which most are triggered by the CodeReuse/ActiveRecord cop.
-
- 30 Jul, 2018 1 commit
-
-
Sean McGivern authored
-
- 29 Jun, 2018 1 commit
-
-
Chantal Rollison authored
-
- 28 Jun, 2018 1 commit
-
-
Chantal Rollison authored
-
- 07 Jun, 2018 3 commits
-
-
Sean McGivern authored
When filtering issues with a search string in a group, we observed on GitLab.com that Postgres was using an inefficient query plan, preferring the (global) trigram indexes on description and title, rather than using a filter on the restricted set of issues within the group. Change the callers of the IssuableFinder to use a CTE in this case to fence the rest of the query from the LIKE filters, so that the optimiser is forced to perform the filter in the order we prefer. This will only force the use of a CTE when: 1. The use_cte_for_search params is truthy. 2. We are using Postgres. 3. We have passed the `search` param. The third item is important - searching issues using the search box does not use the finder in this way, but contructs a query and appends `full_search` to that. For some reason, this query does not suffer from the same issue. Currenly, we only pass this param when filtering issuables (issues or MRs) in a group context.
-
Sean McGivern authored
We had `item_project_ids` to help make slow queries on the dashboard faster, but this isn't necessary any more - the queries are plenty fast, and we forbid searching the dashboard without filters.
-
Sean McGivern authored
When filtering issues with a search string in a group, we observed on GitLab.com that Postgres was using an inefficient query plan, preferring the (global) trigram indexes on description and title, rather than using a filter on the restricted set of issues within the group. Change the callers of the IssuableFinder to use a CTE in this case to fence the rest of the query from the LIKE filters, so that the optimiser is forced to perform the filter in the order we prefer. This will only force the use of a CTE when: 1. The use_cte_for_search params is truthy. 2. We are using Postgres. 3. We have passed the `search` param. The third item is important - searching issues using the search box does not use the finder in this way, but contructs a query and appends `full_search` to that. For some reason, this query does not suffer from the same issue. Currenly, we only pass this param when filtering issuables (issues or MRs) in a group context.
-
- 06 Jun, 2018 1 commit
-
-
Sean McGivern authored
We had `item_project_ids` to help make slow queries on the dashboard faster, but this isn't necessary any more - the queries are plenty fast, and we forbid searching the dashboard without filters.
-
- 21 May, 2018 2 commits
- 09 Apr, 2018 1 commit
-
-
Andreas Brandl authored
This removes the extra check for project-ids which is not needed at all. This does not necessarily reduce execution time of the query, but improves planning time by a few millseconds. Closes #37125.
-
- 04 Apr, 2018 3 commits
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
blackst0ne authored
-
blackst0ne authored
-
- 05 Mar, 2018 1 commit
-
-
Jacopo authored
-
- 23 Feb, 2018 1 commit
-
-
Bob Van Landuyt authored
-
- 22 Feb, 2018 2 commits
-
-
Bob Van Landuyt authored
This ability can be disabled when an external authorization service is enabled.
-
Bob Van Landuyt authored
-
- 21 Feb, 2018 2 commits
-
-
Sean McGivern authored
By extracting a new `filter_items` method, we can override that in the IssuesFinder and MergeRequestsFinder separately, so we don't need checks that the model is the correct one, because we can just use the class we're in to know that. We can do the same for the VALID_PARAMS constant, by making it a class method.
-
Sean McGivern authored
By extracting a new `filter_items` method, we can override that in the IssuesFinder and MergeRequestsFinder separately, so we don't need checks that the model is the correct one, because we can just use the class we're in to know that. We can do the same for the VALID_PARAMS constant, by making it a class method.
-
- 01 Feb, 2018 2 commits
-
-
Jarka Kadlecová authored
# Conflicts: # spec/finders/issues_finder_spec.rb # spec/finders/merge_requests_finder_spec.rb
-
Jarka Kadlecová authored
-
- 05 Jan, 2018 1 commit
-
-
Felipe Artur authored
-
- 13 Nov, 2017 1 commit
-
-
Hiroyuki Sato authored
-
- 27 Sep, 2017 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 26 Sep, 2017 3 commits
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 18 Sep, 2017 1 commit
-
-
haseeb authored
-
- 14 Sep, 2017 1 commit
-
-
Hiroyuki Sato authored
-
- 05 Sep, 2017 1 commit
-
-
Yorick Peterse authored
This changes the issue and MR index pages so the pagination system re-uses the output of the COUNT(*) query used to calculate the number of rows per state (opened, closed, etc). This removes the need for an additional COUNT(*) on both pages.
-
- 31 Aug, 2017 2 commits
-
-
Lin Jen-Shin authored
-
Sean McGivern authored
We're going to cache the total open count separately, and then just perform these counts on the list. We already do that to get the pagination information, through Kaminari, and a future change will make Kaminari reuse the query results from earlier in the request.
-