1. 19 Mar, 2016 1 commit
  2. 15 Mar, 2016 2 commits
    • Rémy Coutable's avatar
      Improving the original label-subscribing implementation · 0c79cd975030
      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
      0c79cd975030
    • Timothy Andrew's avatar
      Original implementation to allow users to subscribe to labels · 6ca2199d0391
      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.
      6ca2199d0391
  3. 11 Mar, 2016 1 commit
  4. 07 Mar, 2016 1 commit
  5. 05 Mar, 2016 1 commit
  6. 02 Mar, 2016 1 commit
  7. 17 Feb, 2016 1 commit
  8. 16 Feb, 2016 1 commit
  9. 15 Feb, 2016 1 commit
    • Rémy Coutable's avatar
      Fix the "x of y" displayed at the top of Issuables' sidebar · 16d58d38137e
      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.
      16d58d38137e
  10. 11 Feb, 2016 1 commit
    • Kirill Zaitsev's avatar
      Add new data to project in push, issue, merge-request and note webhooks data · c6ea19b483b0
      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
      c6ea19b483b0
  11. 10 Feb, 2016 1 commit
  12. 09 Jan, 2016 1 commit
  13. 28 Dec, 2015 1 commit
  14. 24 Dec, 2015 1 commit
  15. 26 Nov, 2015 1 commit
  16. 21 Nov, 2015 1 commit
  17. 20 Nov, 2015 1 commit
  18. 19 Nov, 2015 1 commit
    • Yorick Peterse's avatar
      Use a JOIN in IssuableFinder#by_project · f3f59f405f70
      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.
      f3f59f405f70
  19. 18 Nov, 2015 1 commit
  20. 11 Nov, 2015 1 commit
    • Yorick Peterse's avatar
      Change "recent" scopes to sort by "id" · 75bf88355966
      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.
      75bf88355966
  21. 22 Oct, 2015 1 commit
  22. 16 Oct, 2015 1 commit
  23. 15 Oct, 2015 1 commit
  24. 14 Oct, 2015 2 commits
  25. 16 Sep, 2015 1 commit
  26. 30 Jul, 2015 1 commit
  27. 24 Jul, 2015 1 commit
  28. 24 Apr, 2015 1 commit
  29. 17 Apr, 2015 1 commit
  30. 15 Apr, 2015 1 commit
  31. 02 Apr, 2015 1 commit
  32. 16 Mar, 2015 3 commits
  33. 15 Mar, 2015 1 commit
  34. 06 Feb, 2015 2 commits
  35. 22 Jan, 2015 1 commit