BigW Consortium Gitlab

  1. 09 May, 2016 1 commit
  2. 06 May, 2016 1 commit
  3. 20 Apr, 2016 5 commits
  4. 19 Apr, 2016 1 commit
  5. 02 Apr, 2016 1 commit
  6. 30 Mar, 2016 1 commit
  7. 21 Mar, 2016 1 commit
  8. 19 Mar, 2016 2 commits
  9. 15 Mar, 2016 2 commits
    • Improving the original label-subscribing implementation · 54ec7e95
      Rémy Coutable authored
      1. Make the "subscribed" text in Issuable sidebar reflect the labels
         subscription status
      
      2. Current user mut be logged-in to toggle issue/MR/label subscription
    • Original implementation to allow users to subscribe to labels · 0444fa56
      Timothy Andrew authored
      1. Allow subscribing (the current user) to a label
      
      - Refactor the `Subscription` coffeescript class
        - The main change is that it accepts a container, and conducts all
          DOM queries within its scope. We need this because the labels
          page has multiple instances of `Subscription` on the same page.
      
      2. Creating an issue or MR with labels notifies users subscribed to those labels
      
      - Label `has_many` subscribers through subscriptions.
      
      3. Adding a label to an issue or MR notifies users subscribed to those labels
      
      - This only applies to subscribers of the label that has just been
        added, not all labels for the issue.
  10. 11 Mar, 2016 1 commit
  11. 07 Mar, 2016 1 commit
  12. 05 Mar, 2016 1 commit
  13. 02 Mar, 2016 1 commit
  14. 22 Feb, 2016 2 commits
  15. 17 Feb, 2016 1 commit
  16. 16 Feb, 2016 1 commit
  17. 15 Feb, 2016 1 commit
    • Fix the "x of y" displayed at the top of Issuables' sidebar · 54613b6a
      Rémy Coutable authored
      1. We now display the index of the current issuable among all its project's
      issuables, of the same type and with the same state.
      2. Also, refactored a bit the Issuable helpers into a new IssuablesHelper
      module.
      3. Added acceptance specs for the sidebar counter.
  18. 11 Feb, 2016 1 commit
    • Add new data to project in push, issue, merge-request and note webhooks data · b123171d
      Kirill Zaitsev authored
      - Add `avatar_url`, `description`, `git_ssh_url`, `git_http_url`,
        `path_with_namespace` and `default_branch` in `project` in push, issue,
        merge-request and note webhooks data
      - Deprecate the `ssh_url` in favor of `git_ssh_url` and `http_url` in
        favor of `git_http_url` in `project` for push, issue, merge-request and
        note webhooks data
      - Deprecate the `repository` key in push, issue, merge-request and
        note webhooks data, use `project` instead
  19. 10 Feb, 2016 1 commit
  20. 09 Jan, 2016 1 commit
  21. 28 Dec, 2015 1 commit
  22. 24 Dec, 2015 1 commit
  23. 26 Nov, 2015 1 commit
  24. 21 Nov, 2015 1 commit
  25. 20 Nov, 2015 1 commit
  26. 19 Nov, 2015 1 commit
    • Use a JOIN in IssuableFinder#by_project · 8591cc02
      Yorick Peterse authored
      When using IssuableFinder/IssuesFinder to find issues for multiple
      projects it's more efficient to use a JOIN + a "WHERE project_id IN"
      condition opposed to running a sub-query.
      
      This change means that when finding issues without labels we're now
      using the following SQL:
      
          SELECT issues.*
          FROM issues
          JOIN projects ON projects.id = issues.project_id
      
          LEFT JOIN label_links ON label_links.target_type = 'Issue'
                                AND label_links.target_id  = issues.id
      
          WHERE (
              projects.id IN (...)
              OR projects.visibility_level IN (20, 10)
          )
          AND issues.state IN ('opened','reopened')
          AND label_links.id IS NULL
          ORDER BY issues.id DESC;
      
      instead of:
      
          SELECT issues.*
          FROM issues
          LEFT JOIN label_links ON label_links.target_type = 'Issue'
                                AND label_links.target_id  = issues.id
      
          WHERE issues.project_id IN (
              SELECT id
              FROM projects
              WHERE id IN (...)
              OR visibility_level IN (20,10)
          )
          AND issues.state IN ('opened','reopened')
          AND label_links.id IS NULL
          ORDER BY issues.id DESC;
      
      The big benefit here is that in the last case PostgreSQL can't properly
      use all available indexes. In particular it ends up performing a
      sequence scan on the "label_links" table (processing around 290 000
      rows). The new query is roughly 2x as fast as the old query.
  27. 18 Nov, 2015 1 commit
  28. 11 Nov, 2015 1 commit
    • Change "recent" scopes to sort by "id" · 7eb502c0
      Yorick Peterse authored
      These scopes can just sort by the "id" column in descending order to
      achieve the same result. An added benefit is being able to perform a
      backwards index scan (depending on the rest of the final query) instead
      of having to actually sort data.
  29. 22 Oct, 2015 1 commit
  30. 16 Oct, 2015 1 commit
  31. 15 Oct, 2015 1 commit
  32. 14 Oct, 2015 2 commits