1. 22 Feb, 2019 1 commit
  2. 21 Feb, 2019 1 commit
  3. 28 Jan, 2019 1 commit
    • Mario de la Ossa's avatar
      Save sorting preference for Issues/MRs in BE · 49c74068
      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
      49c74068
  4. 12 Dec, 2018 1 commit
  5. 06 Dec, 2018 1 commit
  6. 03 Dec, 2018 1 commit
  7. 30 Nov, 2018 1 commit
    • Sean McGivern's avatar
      Add a flag to use a subquery for group issues search · 7fd5dbf9
      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.
      7fd5dbf9
  8. 14 Nov, 2018 1 commit
  9. 19 Sep, 2018 1 commit
    • gfyoung's avatar
      Enable frozen string in app/controllers/**/*.rb · 73322a0e
      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.
      73322a0e
  10. 11 Sep, 2018 1 commit
  11. 04 Sep, 2018 1 commit
  12. 21 Aug, 2018 1 commit
  13. 07 Jun, 2018 1 commit
    • Sean McGivern's avatar
      Force Postgres to avoid trigram indexes when in a group · c03386c3
      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.
      c03386c3
  14. 06 Jun, 2018 1 commit
    • Sean McGivern's avatar
      Simplify issuable finder queries · 57e6a98c
      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.
      57e6a98c
  15. 28 Apr, 2018 1 commit
  16. 24 Apr, 2018 1 commit
  17. 02 Mar, 2018 1 commit
    • Jan Provaznik's avatar
      Support additional LabelsFinder parameters for group labels · 911fd7c2
      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).
      911fd7c2
  18. 21 Feb, 2018 1 commit
    • Sean McGivern's avatar
      Refactor IssuableFinder to extract model-specific logic · c2fc4066
      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.
      c2fc4066
  19. 01 Feb, 2018 1 commit
  20. 30 Jan, 2018 1 commit
    • Jan Provaznik's avatar
      Make pagination optional for issuables · b02a6bed
      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
      b02a6bed
  21. 23 Nov, 2017 1 commit
    • Sean McGivern's avatar
      Use latest_merge_request_diff association · 991bf24e
      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.
      991bf24e
  22. 22 Nov, 2017 1 commit
  23. 17 Nov, 2017 1 commit
  24. 07 Nov, 2017 1 commit
  25. 06 Nov, 2017 1 commit
  26. 26 Sep, 2017 1 commit
  27. 23 Sep, 2017 1 commit
  28. 18 Sep, 2017 2 commits
  29. 07 Sep, 2017 1 commit
  30. 05 Sep, 2017 1 commit
    • Yorick Peterse's avatar
      Re-use issue/MR counts for the pagination system · 42062a45
      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.
      42062a45
  31. 28 Aug, 2017 1 commit
  32. 19 Jul, 2017 1 commit
    • Sean McGivern's avatar
      Fix issuable state caching · b3a588bc
      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!
      b3a588bc
  33. 09 Jul, 2017 1 commit
  34. 06 Jul, 2017 1 commit
    • Sean McGivern's avatar
      Add table for merge request commits · aff5c9f3
      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.
      aff5c9f3
  35. 08 May, 2017 1 commit
  36. 04 May, 2017 1 commit
  37. 04 Apr, 2017 1 commit
  38. 21 Feb, 2017 1 commit
  39. 16 Feb, 2017 1 commit