An error occurred fetching the project authors.
- 14 Nov, 2018 1 commit
-
-
Heinrich Lee Yu authored
-
- 19 Sep, 2018 1 commit
-
-
gfyoung authored
Enables frozen string for the following: * app/controllers/*.rb * app/controllers/admin/**/*.rb * app/controllers/boards/**/*.rb * app/controllers/ci/**/*.rb * app/controllers/concerns/**/*.rb Partially addresses #47424.
-
- 11 Sep, 2018 1 commit
-
-
Yorick Peterse authored
This whitelists all existing offenses for the various CodeReuse cops, of which most are triggered by the CodeReuse/ActiveRecord cop.
-
- 04 Sep, 2018 1 commit
-
-
Stan Hu authored
Closes #49120
-
- 21 Aug, 2018 1 commit
-
-
🙈 jacopo beschi 🙉 authored
-
- 07 Jun, 2018 1 commit
-
-
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.
-
- 28 Apr, 2018 1 commit
-
-
blackst0ne authored
This commits replaces `params` with `safe_params` in `url_for` helpers to resolve security issues [1] and failing specs with the ``` ArgumentError: Attempting to generate a URL from non-sanitized request parameters! An attacker can inject malicious data into the generated URL, such as changing the host. Whitelist and sanitize passed parameters to be secure. ``` error. [1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/45168
-
- 24 Apr, 2018 1 commit
-
-
Sean McGivern authored
-
- 02 Mar, 2018 1 commit
-
-
Jan Provaznik authored
In some situations (listing labels for epics) we want to list only group ancestor labels, this is already supported in LabelsFinder we just need to enable additional parameters. Also `set_issuables_index` method now loads project labels only if @project is set (which is not used for epic group labels).
-
- 21 Feb, 2018 1 commit
-
-
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 1 commit
-
-
Jarka Kadlecová authored
-
- 30 Jan, 2018 1 commit
-
-
Jan Provaznik authored
On epics roadmap page we list all epics in the given time frame without pagination (at least for the first iteration), in this case it would be nice to use the existing issuables index logic except pagination (see MR gitlab-ee!4281). For this reason this patch allows to easily disable pagination. Related gitlab-ee!4281
-
- 23 Nov, 2017 1 commit
-
-
Sean McGivern authored
Compared to the merge_request_diff association: 1. It's simpler to query. The query uses a foreign key to the merge_request_diffs table, so no ordering is necessary. 2. It's faster for preloading. The merge_request_diff association has to load every diff for the MRs in the set, then discard all but the most recent for each. This association means that Rails can just query for N diffs from N MRs. 3. It's more complicated to update. This is a bidirectional foreign key, so we need to update two tables when adding a diff record. This also means we need to handle this as a special case when importing a GitLab project. There is some juggling with this association in the merge request model: * `MergeRequest#latest_merge_request_diff` is _always_ the latest diff. * `MergeRequest#merge_request_diff` reuses `MergeRequest#latest_merge_request_diff` unless: * Arguments are passed. These are typically to force-reload the association. * It doesn't exist. That means we might be trying to implicitly create a diff. This only seems to happen in specs. * The association is already loaded. This is important for the reasons explained in the comment, which I'll reiterate here: if we a) load a non-latest diff, then b) get its `merge_request`, then c) get that MR's `merge_request_diff`, we should get the diff we loaded in c), even though that's not the latest diff. Basically, `MergeRequest#merge_request_diff` is the latest diff in most cases, but not quite all.
-
- 22 Nov, 2017 1 commit
-
-
Lin Jen-Shin authored
And use .rubocop.yml to exclude paths we don't care, rather than using the cop itself to exclude.
-
- 17 Nov, 2017 1 commit
-
-
Lin Jen-Shin authored
-
- 07 Nov, 2017 1 commit
-
-
Jarka Kadlecova authored
-
- 06 Nov, 2017 1 commit
-
-
Lin Jen-Shin authored
-
- 26 Sep, 2017 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 23 Sep, 2017 1 commit
-
-
Vitaliy @blackst0ne Klachkov authored
-
- 18 Sep, 2017 2 commits
-
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
-
- 07 Sep, 2017 1 commit
-
-
Sean McGivern authored
This makes it easier to reuse in EE.
-
- 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.
-
- 28 Aug, 2017 1 commit
-
-
Yorick Peterse authored
This ensures the project of an MR's head pipeline is eager loaded, preventing an N+1 query problem from occurring when viewing the list of MRs of a project.
-
- 19 Jul, 2017 1 commit
-
-
Sean McGivern authored
We were including controller params in the cache key, so the key for the header didn't match the one for the list itself!
-
- 09 Jul, 2017 1 commit
-
-
Stan Hu authored
Closes #34159
-
- 06 Jul, 2017 1 commit
-
-
Sean McGivern authored
This is an ID-less table with just three columns: an association to the merge request diff the commit belongs to, the relative order of the commit within the merge request diff, and the commit SHA itself. Previously we stored much more information about the commits, so that we could display them even when they were deleted from the repo. Since 8.0, we ensure that those commits are kept around for as long as the target repo itself is, so we don't need to duplicate that data in the database.
-
- 08 May, 2017 1 commit
-
-
Felipe Artur authored
-
- 04 May, 2017 1 commit
-
-
Valery Sizov authored
-
- 04 Apr, 2017 1 commit
-
-
mhasbini authored
-
- 21 Feb, 2017 1 commit
-
-
blackst0ne authored
-
- 16 Feb, 2017 3 commits
-
-
blackst0ne authored
-
blackst0ne authored
-
blackst0ne authored
-
- 09 Feb, 2017 1 commit
-
-
Felipe Artur authored
-
- 18 Nov, 2016 1 commit
-
-
Douwe Maan authored
-
- 22 Sep, 2016 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 20 Sep, 2016 1 commit
-
-
barthc authored
-
- 18 Aug, 2016 1 commit
-
-
Sean McGivern authored
The sort orders used to be id_asc / id_desc, and are now created_asc / created_desc. Users can still have cookies containing the old sort orders, or bookmarks to links specifying them, so convert these to the new versions quietly.
-