An error occurred fetching the project authors.
- 06 Nov, 2020 1 commit
-
-
Sean McGivern authored
This reverts merge request !45738
-
- 05 Nov, 2020 1 commit
-
-
David Kim authored
This reverts merge request !45602
-
- 19 Oct, 2020 1 commit
-
- 16 Oct, 2020 1 commit
-
-
David Kim authored
- It loads review requested MRs as part of Assignee filter - We would probably want a dedicated filter for it down the track, but this is our first iteration
-
- 14 Oct, 2020 2 commits
-
-
Nick Thomas authored
-
Nick Thomas authored
On the MR list page, we like to display how many issues were found from the filtered search query *in total*. However, especially when the filter includes conditions on the MR title or description, this can be very expensive to calculate, and involve reading gigabytes of text data from the database. As long as the data is already in the page cache, this usually finishes within the 15-second timeout on GitLab.com, but if the database cache is cold, a statement timeout is the usual occurrence. More generally, it's not very clever to spend so much time calculating a piece of information with marginal value. This MR applies a shorter limit to the counting statements and provides for graceful fallback to a '?' value, with a nice tooltip, if the query times out. This means we're able to view the results in a reasonable time, rather than the page taking a long time to load, or not loading at all.
-
- 05 Aug, 2020 1 commit
-
-
Doug Stull authored
- follow style guide
-
- 17 Jul, 2020 1 commit
-
-
Phil Hughes authored
This moves some approvals rules into FOSS which will be a simpler version of our approval rules and pnly require a single approve button to be shown https://gitlab.com/gitlab-org/gitlab/-/issues/27426
-
- 13 Jul, 2020 1 commit
-
-
Felipe Artur authored
Part of the plan to move service desk feature into core tier. More info: https://gitlab.com/gitlab-org/gitlab/-/issues/215364
-
- 27 May, 2020 1 commit
-
-
Felipe Artur authored
Turn IssuableMetadata concern into a class. This refactoring allows EE only metadata to have its logic on ee folder.
-
- 14 Nov, 2019 1 commit
-
-
Igor authored
The number of diff commits can be overwhelming sometimes and preloading them and iterating over them using map can be very expensive We'd better make multiple limited requests (even if it's N+1) then running into a subtle case when thousands of elements are loaded into memory and iterated
-
- 10 Sep, 2019 1 commit
-
-
Markus Koller authored
We had similar code in a few places to redirect to the last page if the given page number is out of range. This unifies the handling in a new controller concern and adds usage of it in all snippet listings.
-
- 21 Aug, 2019 2 commits
-
-
George Koltsov authored
Sorting preference functionality has been extracted from `IssuableCollections` to a new `SortingPreference` concern in order to reuse this functionality in projects (and groups in the future).
-
-
- 06 Aug, 2019 1 commit
-
-
Pavel Shutsin authored
-
- 30 Jul, 2019 1 commit
-
-
Yorick Peterse authored
All instances of injecting an EE specific module have been changed to use the new methods for this: prepend_if_ee, extend_if_ee, and include_if_ee. This allows these lines to be included in CE, even when the modules to inject do not exist. This in turn allows us to backport these lines to CE and keep them there, instead of having to strip them out.
-
- 21 Jun, 2019 1 commit
-
-
Alexandru Croitor authored
Count issues related merge requests based on user access level. And issue can have related MRs from projects where user does not have access so the number of related merge requests should be adjusted based on user's ability to access the related MRs. https://gitlab.com/gitlab-org/gitlab-ce/issues/59581
-
- 18 Jun, 2019 2 commits
-
-
Alexandru Croitor authored
Count issues related merge requests based on user access level. And issue can have related MRs from projects where user does not have access so the number of related merge requests should be adjusted based on user's ability to access the related MRs. https://gitlab.com/gitlab-org/gitlab-ce/issues/59581
-
Riccardo Padovani authored
-
- 29 May, 2019 1 commit
-
-
Brett Walker authored
- adding a "Manual" option to the dropdown - show 100 issues list when manually sorting
-
- 28 May, 2019 1 commit
-
-
Brett Walker authored
- adding a "Manual" option to the dropdown - show 100 issues list when manually sorting
-
- 09 Apr, 2019 1 commit
-
-
Oswaldo Ferreira authored
This mainly handles the search and replace approach to using assignees instead assignee for merge requests. It reuses existing logic from Issuable, where now issues _and_ merge requests handles multiple assignees. The feature is behind a feature flag, though, there's no way to switch back and forth to using the old and new tables. That's because we'd need a "sync" approach: Once the feature is off, we'd have to sync old table with new table, once it's on, new table with old table. Using the new `merge_request_assignees` altogether will make things simpler to handle, even though it's a bit "riskier".
-
- 08 Apr, 2019 1 commit
-
-
Oswaldo Ferreira authored
Backports https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10161 (code out of ee/ folder).
-
- 04 Apr, 2019 1 commit
-
-
Sean McGivern authored
When we use the `search` param on an `IssuableFinder`, we can run into issues. We have trigram indexes to support these searches. On GitLab.com, we often see Postgres's optimiser prioritise the (global) trigram indexes over the index on `project_id`. For group and project searches, we know that it will be quicker to filter by `project_id` first, as it returns fewer rows in most cases. For group issues search, we ran into this issue previously, and went through the following iterations: 1. Use a CTE on the project IDs as an optimisation fence. This prevents the planner from disregarding the index on `project_id`. Unfortunately it breaks some types of sorting, like priority and popularity, as they sort on a joined table. 2. Use a subquery for listing issues, and a CTE for counts. The subquery - in the case of group lists - didn't help as much as the CTE, but was faster than not including it. We can safely use a CTE for counts as they don't have sorting. Now, however, we're seeing the same issue in a project context. The subquery doesn't help at all there (it would only return one row, after all). In an attempt to keep total code complexity under control, this commit removes the subquery optimisation and applies the CTE optimisation only for sorts we know that are safe. This means that for more complicated sorts (like priority and popularity), the search will continue to be very slow. If this is a high-priority issue, we can consider introducing further optimisations, but this finder is already very complicated and additional complexity has a cost. The group CTE optimisation is controlled by the same feature flag as before, `attempt_group_search_optimizations`, which is enabled by default. The new project CTE optimisation is controlled by a new feature flag, `attempt_project_search_optimizations`, which is disabled by default.
-
- 26 Feb, 2019 2 commits
-
-
Kamil Trzciński authored
Ability to filter confidential issues Closes #50747 See merge request gitlab-org/gitlab-ce!24960
-
Kamil Trzciński authored
Ability to filter confidential issues Closes #50747 See merge request gitlab-org/gitlab-ce!24960
-
- 25 Feb, 2019 2 commits
-
-
Michael Kozono authored
This reverts commit d133bf84, reversing changes made to 7981c029.
-
Rémy Coutable authored
This reverts commit 82d7b5a0
-
- 22 Feb, 2019 1 commit
-
-
Robert Schilling authored
Use internally only boolean params.
-
- 21 Feb, 2019 1 commit
-
-
Robert Schilling authored
Add a new search bar filter for confidential issues. Add filtering support to the IssuesFinder.
-
- 28 Jan, 2019 2 commits
-
-
Mario de la Ossa authored
Backporting some required changes to EE classes to support saving sort column and direction to the backend
-
Mario de la Ossa authored
In order to let users' sorting preferences transfer between devices, we save the preference for issues and MRs (one preference for issues, one for MRs) in the backend inside the UserPreference object
-
- 24 Jan, 2019 1 commit
-
-
Andy Steele authored
-
- 18 Dec, 2018 1 commit
-
-
Mario de la Ossa authored
We accidentally removed the ability to sort issues by weight when porting a sorting change to EE, so this fixes that.
-
- 12 Dec, 2018 2 commits
-
-
Yorick Peterse authored
The automatic merging code used `--strategy=ours`, which turned out to be incorrect; instead we wanted `--strategy=recursive --strategy-option=ours`. This small difference results in merging throwing away _all_ EE changes in favour of CE changes, instead of only doing this for conflicts. This commit ensures that EE has all the appropriate changes. The diff was generated by cherry picking all merge commits made since two days ago, picking them with `--strategy=recursive --strategy-option=ours`.
-
Felipe Artur authored
-
- 06 Dec, 2018 1 commit
-
-
Fatih Acet authored
-
- 05 Dec, 2018 1 commit
-
-
Mario de la Ossa authored
-
- 03 Dec, 2018 1 commit
-
-
Felipe Artur authored
-
- 30 Nov, 2018 1 commit
-
-
Sean McGivern authored
We already had a flag to use a CTE, but this broke searching in some cases where we need to sort by a joined table. Disabling the CTE flag makes searches much slower. The new flag, to use a subquery, makes them slightly slower than the CTE, while maintaining correctness. If both it and the CTE flag are enabled, the subquery takes precedence.
-