BigW Consortium Gitlab

  1. 16 May, 2016 17 commits
    • Reduce duplication and branching logic in EventsHelper · 020e6168
      Robert Speicher authored
      Remove unused methods from Event model
    • Remove redundant `html_escape` calls from `title` attributes · 8a7b5b17
      Robert Speicher authored
      These get escaped automatically.
    • Fix titles for commit references in Event feed · 3950f807
      Robert Speicher authored
      Prior, the `title` attribute was being included as an argument to the
      route helper rather than as an argument to `link_to`.
    • Simplify Event's target type-checking · c05ed99b
      Robert Speicher authored
    • Add an Event's target's title to its reference link · 6286b28b
      Robert Speicher authored
      Given an activity feed entry like:
      
      > Douwe Maan commented on [issue #123] at [gitlab-org/gitlab-ce]
      
      ...the `issue #123` link will now have a `title` attribute.
    • Merge branch… · a511a122
      Douwe Maan authored
      Merge branch '17227-upcoming-milestone-is-confusing-when-projects-have-different-milestones' into 'master'
      
      Make upcoming milestone work across projects
      
      Before: we took the next milestone due across all projects in the
      search and found issues whose milestone title matched that
      one. Problems:
      
      1. The milestone could be closed.
      2. Different projects have milestones with different schedules.
      3. Different projects have milestones with different titles.
      4. Different projects can have milestones with different schedules, but
         the _same_ title. That means we could show issues from a past
         milestone, or one that's far in the future.
      
      After: gather the ID of the next milestone on each project we're looking
      at, and find issues with those milestone IDs. Problems:
      
      1. For a lot of projects, this can return a lot of IDs.
      2. The SQL query has to be different between Postgres and MySQL, because
         MySQL is much more lenient with HAVING: as well as the columns
         appearing in GROUP BY or in aggregate clauses, MySQL allows them to
         appear in the SELECT list (un-aggregated).
      
      Closes #17227.
      
      See merge request !4125
    • Merge branch… · f2343889
      Robert Speicher authored
      Merge branch '13691-allow-admin-to-reset-user-password-and-force-password-reset-on-next-login' into 'master'
      
      Force password change after admin reset
      
      Closes #13691.
      
      See merge request !4016
    • Merge branch 'docker-registry' into 'master' · 59e62fc4
      Douwe Maan authored
      Added authentication service for docker registry
      
      This adds a simple authentication service for docker which uses current user credentials to authenticate pulls and pushes.
      
      I have only one concern. Since the `.docker/config` is unencrypted, thus the password for user stored there is unencrypted, maybe we should from the start implement function to generate/provide a separate password just for the purposes of accessing docker registry?
      
      What do you think @jacobvosmaer @sytses @marin?
      
      cc @marin 
      
      See merge request !3787
    • Merge branch 'gh-pull-requests' · 5dd013f1
      Douwe Maan authored
    • Return a relation with Postgres · e8058bd2
      Sean McGivern authored
      Postgres only needs to select a single column, so that can used as a
      sub-query where `Milestone.upcoming_ids_by_projects` is actually used in
      `IssuableFinder`.
      
      MySQL needs to select the `due_date` column because it's used in the
      `HAVING` clause, so it has to return an array of IDs.
    • Make upcoming milestone work across projects · 750b2ff0
      Sean McGivern authored
      Before: we took the next milestone due across all projects in the
      search and found issues whose milestone title matched that
      one. Problems:
      
      1. The milestone could be closed.
      2. Different projects have milestones with different schedules.
      3. Different projects have milestones with different titles.
      4. Different projects can have milestones with different schedules, but
         the _same_ title. That means we could show issues from a past
         milestone, or one that's far in the future.
      
      After: gather the ID of the next milestone on each project we're looking
      at, and find issues with those milestone IDs. Problems:
      
      1. For a lot of projects, this can return a lot of IDs.
      2. The SQL query has to be different between Postgres and MySQL, because
         MySQL is much more lenient with HAVING: as well as the columns
         appearing in GROUP BY or in aggregate clauses, MySQL allows them to
         appear in the SELECT list (un-aggregated).
    • Tidy up IssuesFinder specs · 91480e5e
      Sean McGivern authored
      - Don't do setup in spec bodies.
      - Don't `describe` a symbol.
      - Don't use 'should'.
    • Force password change after admin reset · bec35052
      Sean McGivern authored
      When an admin changes a user's password for them, force the user to
      reset the password after logging in by expiring the new password
      immediately.
    • Merge branch 'add-cache-count-metrics' into 'master' · 78a67fc4
      Yorick Peterse authored
      Add cache count metrics to rails cache
      
      See merge request !4157
  2. 15 May, 2016 7 commits
  3. 14 May, 2016 11 commits
  4. 13 May, 2016 5 commits