- 23 Jan, 2018 1 commit
-
-
Jan Provaznik authored
Search query is especially slow if a user searches a generic string which matches many records, in such case search can take tens of seconds or time out. To speed up the search query, we search only for first 1000 records, if there is >1000 matching records we just display "1000+" instead of precise total count supposing that with such amount the exact count is not so important for the user. Because for issues even limited search was not fast enough, 2-phase approach is used for issues: first we use simpler/faster query to get all public issues, if this exceeds the limit, we just return the limit. If the amount of matching results is lower than limit, we re-run more complex search query (which includes also confidential issues). Re-running the complex query should be fast enough in such case because the amount of matching issues is lower than limit. Because exact total_count is now limited, this patch also switches to to "prev/next" pagination. Related #40540
-
- 22 Jan, 2018 2 commits
-
-
Bob Van Landuyt authored
Otherwise we'd only preload the ancestors that would fit the page. That way, when a search result was on the first page, but the ancestor didn't fit the page anymore. We would not have the preloaded ancestor when rendering the hierarchy.
-
Bob Van Landuyt authored
When a project is shared with a group, it should not be included as a descendant on the group dashboard.
-
- 18 Jan, 2018 1 commit
-
-
Felipe Artur authored
-
- 17 Jan, 2018 1 commit
-
-
Robert Speicher authored
Remove order param from the MilestoneFinder See merge request gitlab/gitlabhq!2259 (cherry picked from commit 14408042e78f2ebc2644f956621b461dbfa3d36d) 155881e7 Remove order param from the MilestoneFinder
-
- 11 Jan, 2018 1 commit
-
-
🙈 jacopo beschi 🙉 authored
-
- 05 Jan, 2018 1 commit
-
-
Felipe Artur authored
-
- 04 Jan, 2018 1 commit
-
-
Felipe Artur authored
-
- 04 Dec, 2017 1 commit
-
-
Francisco Javier López authored
-
- 28 Nov, 2017 2 commits
-
-
Matija Čupić authored
-
Matija Čupić authored
-
- 27 Nov, 2017 4 commits
-
-
Tomasz Maczukin authored
-
Matija Čupić authored
-
Matija Čupić authored
-
Matija Čupić authored
-
- 24 Nov, 2017 1 commit
-
-
Douwe Maan authored
-
- 16 Nov, 2017 1 commit
-
-
Jacopo authored
Adds a rubocop rule (with autocorrect) to ensure line break after guard clauses.
-
- 13 Nov, 2017 2 commits
-
-
Sean McGivern authored
We should include users who have access from parent groups, not just direct members of the current group.
-
Hiroyuki Sato authored
-
- 06 Nov, 2017 2 commits
-
-
Markus Koller authored
-
Markus Koller authored
-
- 23 Oct, 2017 1 commit
-
-
George Andrinopoulos authored
-
- 12 Oct, 2017 1 commit
-
-
Bob Van Landuyt authored
-
- 11 Oct, 2017 1 commit
-
-
Bob Van Landuyt authored
-
- 10 Oct, 2017 4 commits
-
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
- 07 Oct, 2017 2 commits
-
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
- 05 Oct, 2017 2 commits
-
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
- 04 Oct, 2017 8 commits
-
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
When projects were listed after groups, the projects that would also have been listed on the last page containing groups would be repeated.
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
When filtering we want all to preload all the ancestors upto the specified parent group. - root - subgroup - nested-group - project So when searching 'project', on the 'subgroup' page we want to preload 'nested-group' but not 'subgroup' or 'root'
-
Bob Van Landuyt authored
And fix some pagination bugs
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
-
Bob Van Landuyt authored
By preloading the count of members, projects and subgroups of a group, we don't need to query them later. We also preload the entire hierarchy for a search result and include the counts so we don't need to query for them again
-