An error occurred fetching the project authors.
  1. 15 Dec, 2016 1 commit
  2. 14 Dec, 2016 2 commits
  3. 01 Dec, 2016 1 commit
  4. 30 Nov, 2016 1 commit
  5. 25 Nov, 2016 1 commit
    • Yorick Peterse's avatar
      Refresh project authorizations using a Redis lease · 92b2c74c
      Yorick Peterse authored
      When I proposed using serializable transactions I was hoping we would be
      able to refresh data of individual users concurrently. Unfortunately
      upon closer inspection it was revealed this was not the case. This could
      result in a lot of queries failing due to serialization errors,
      overloading the database in the process (given enough workers trying to
      update the target table).
      
      To work around this we're now using a Redis lease that is cancelled upon
      completion. This ensures we can update the data of different users
      concurrently without overloading the database.
      
      The code will try to obtain the lease until it succeeds, waiting at
      least 1 second between retries. This is necessary as we may otherwise
      end up _not_ updating the data which is not an option.
      92b2c74c
  6. 23 Nov, 2016 4 commits
  7. 22 Nov, 2016 1 commit
  8. 19 Nov, 2016 1 commit
  9. 18 Nov, 2016 2 commits
  10. 17 Nov, 2016 2 commits
  11. 16 Nov, 2016 2 commits
  12. 07 Nov, 2016 3 commits
  13. 04 Nov, 2016 1 commit
  14. 01 Nov, 2016 1 commit
    • Yar's avatar
      Allow to search for user by secondary email address in the admin interface · f8530580
      Yar authored
      It is not possible to search for a user by his secondary email address in
      the Users search bar in the admin interface(/admin/users). A use-case could
       be that an admin wants to remove a specific secondary email address of an
      user, because it interferes with another user. Issue #23761
      
      This commit adds ability to search not only by main email, but also
      by any secondary email in the admin interface.
      f8530580
  15. 27 Oct, 2016 1 commit
    • Steve Halasz's avatar
      Only show one error message for an invalid email · 36ec5eaf
      Steve Halasz authored
      If notification_email is blank, it's set from email. If an admin
      attempted to create a user with an invalid email, an error would be
      displayed for both fields. Only validate the notification_email if it's
      different from email.
      36ec5eaf
  16. 25 Oct, 2016 1 commit
    • Timothy Andrew's avatar
      Fix `User#to_reference` · fed3f718
      Timothy Andrew authored
      1. Changes in 8.13 require `Referable`s that don't have a project
         reference to accept two arguments - `from_project` and
         `target_project`.
      
      2. `User#to_reference` was not changed to accept the
         `target_project` (even though it is not used). Moving an issue
         containing a user reference would throw a "invalid number of
         arguments" exception.
      
      Fixes #23662
      fed3f718
  17. 24 Oct, 2016 1 commit
  18. 17 Oct, 2016 1 commit
  19. 11 Oct, 2016 1 commit
  20. 07 Oct, 2016 1 commit
  21. 05 Oct, 2016 1 commit
    • Yorick Peterse's avatar
      Refactor Gitlab::Identifier · 16ed9b61
      Yorick Peterse authored
      This refactors Gitlab::Identifier so it uses fewer queries and is
      actually tested. Queries are reduced by caching the output as well as
      using 1 query (instead of 2) to find a user using an SSH key.
      16ed9b61
  22. 04 Oct, 2016 1 commit
    • Sean McGivern's avatar
      Restrict failed login attempts for users with 2FA · 194fbc3c
      Sean McGivern authored
      Copy logic from `Devise::Models::Lockable#valid_for_authentication?`, as
      our custom login flow with two pages doesn't call this method. This will
      increment the failed login counter, and lock the user's account once
      they exceed the number of failed attempts.
      
      Also ensure that users who are locked can't continue to submit 2FA
      codes.
      194fbc3c
  23. 15 Sep, 2016 2 commits
  24. 01 Sep, 2016 2 commits
    • Robert Speicher's avatar
      Merge branch 'refactor/add-policies' into 'master' · a7657098
      Robert Speicher authored
      Refactor ability.rb into Policies
      
      Factors out `ability.rb` into a new abstraction - the "policy" (stored in `app/policies`). A policy is a class named `#{class_name}Policy` (looked up automatically as needed) that implements `rules` as follows:
      
      ``` ruby
      class ThingPolicy < BasePolicy
        def rules
          @user # this is a user to determine abilities for, optionally nil in the anonymous case
          @subject # this is the subject of the ability, guaranteed to be an instance of `Thing`
          can! :some_ability # grant the :some_ability permission
          cannot! :some_ability # ensure that :some_ability is not allowed. this overrides any `can!` that is called before or after
          delegate! @subject.other_thing # merge the abilities (can!) and prohibitions (cannot!) from `@subject.other_thing`
          can? :some_ability # test whether, so far, :some_ability is allowed
        end
      
        def anonymous_rules
          # optional. if not implemented `rules` is called where `@user` is nil. otherwise this method is called when `@user` is nil.
        end
      end
      ```
      
      See merge request !5796
      a7657098
    • Felipe Artur's avatar
      Project tools visibility level · 892dea67
      Felipe Artur authored
      892dea67
  25. 30 Aug, 2016 1 commit
  26. 24 Aug, 2016 1 commit
  27. 20 Aug, 2016 2 commits
    • Douwe Maan's avatar
      Merge branch '674-protected-branch-specific-people' into 'master' · f6bb1db8
      Douwe Maan authored
      Restrict pushes / merges to a protected branch to specific people
      
      - Closes #674
      - Related to #179
      
      ![2016-08-04_16-19-12](/uploads/c81032fe262949f3084974c4e622e9eb/2016-08-04_16-19-12.png)
      ![](https://gitlab.com/gitlab-org/gitlab-ee/uploads/342f06078b07b39c2c817b12c81b30fe/Screen_Shot_2016-07-27_at_6.50.56_PM.png)
      ![](https://gitlab.com/gitlab-org/gitlab-ee/uploads/52fe1ae3027d491270ea4845ae7ce54b/Screen_Shot_2016-07-27_at_6.51.02_PM.png)
      
      - [ ]  ee#674 !581 Restrict merges to specific people
          - [x]  Implementation
              - [x]  Model changes
                  - [x]  Protected branch `has_many` access levels
              - [x]  Frontend
                  - [x]  How to add new users / roles?
                  - [x]  Dropdown should include users
                  - [x]  Dropdown shouldn't include users / roles that have already been selected
                  - [x]  Allow removing users / roles
              - [x]  Removing a user from the project should remove their access (?)
          - [x]  Test/refactor
              - [x]  Extract common from {Merge,Push}AccessLevel models
              - [x]  Clean up code that's removing users/roles that are already selected
              - [x]  AccessLevelController?
              - [x]  Fix build
              - [x]  Add more tests
          - [x]  Non `:push_code` users can't push even if added to an access level
          - [x]  Remove access levels when a user is removed from a project
          - [x]  Rebase off EE master instead of the "no one can push" feature branch
              - [x]  Fix create for roles
              - [x]  Fix update for roles
              - [x]  Fix delete
              - [x]  Fix create for users
              - [x]  Fix update for users
              - [x]  Fix defaults
          - [x]  Verify
              - [x]  API
                  - [x]  For a developer user
                      - [x]  When they are granted access specifically to
                          - [x]  Merge
                          - [x]  Push
                  - [x]  For a reporter user
                      - [x]  When they are granted access specifically to
                          - [x]  Merge
                          - [x]  Push
              - [x]  Default branch protection
          - [x]  CHANGELOG
          - [x]  Screenshots
          - [x]  Only show `:push_code` users in the dropdown
          - [x]  Send email when user is added/removed from a protected branch
          - [x]  Assign to {mini,end}boss
          - [x]  Fix build
          - [x]  Implement @dbalexandre's review comments
          - [x]  EE should _add_ to CE
          - [x]  Wait for [build](https://gitlab.com/gitlab-org/gitlab-ee/commit/61edf43d31452a0b972dc880e277c825d59f764f/builds) to pass
          - [x]  Test by hand
          - [x]  Assign to endboss
          - [x]  Create CE MR to backport changes
          - [x]  Implement @Douwe's comments
              - [x]  access_level#humanize
              - [x]  Blank line in _protected_branch.html.haml
              - [x]  move stuff into shared partials? (_protected_branch_ee.html.haml)
              - [x]  Can we move stuff into shared partials? (_create_protected_branch_ee.html.haml)
              - [x]  The CE version has a bunch of extra attributes here, do we need those?
              - [x]  We can't indent this section just in EE (protected_branches/show.html.haml)
              - [x]  In EE, try not to add stuff to existing views. (protected_branches/show.html.haml)
              - [x]  If we're gonna change multiline blocks to single-line blocks, we need to so in CE too. (factory)
              - [x]  Split up `ProtectedBranches#show`
          - [x]  Wait for [build](https://gitlab.com/gitlab-org/gitlab-ee/commit/3943254d5f92c9be520f685044d23bf75282d42a/builds)
          - [x]  Implement Douwe's suggestions
          - [x]  Add uniqueness validation
          - [x]  Wait for @alfredo's UI enhancements
          - [x]  Remove `show` page access controls
          - [x]  Add more feature specs
          - [ ]  Wait for review for @alfredo's work
          - [ ]  Wait for merge
      
      See merge request !581
      f6bb1db8
    • Timothy Andrew's avatar
      Implement model-level changes to allow branch protection for specific users. · d78ab154
      Timothy Andrew authored
      - A protected branch now `has_many` access levels (as opposed to
        `has_one`, which CE will continue to have). Each access level
        represents either a user or a role that is allowed to access the
        protected branch.
      
      - Update `git_access_spec` to test cases where a specific user is given
        access to a protected branch.
      
      - Remove the explicit `push_check` for protected branches. This is
        because a non-developer user (such as a reporter) should be able to
        push code if they are added to a protected branch specifically.
      
      - Fix specs (git_access_spec) that were implicitly depending on a
        master push access level being created (previously, a protected
        branch's default state was "masters can push + masters can merge").
        Since the current default is "none", the dependency needs to be
        explicitly declared.
      
      - Update `git_push_service` so default branch protection (for new repos)
        works as expected.
      d78ab154
  28. 17 Aug, 2016 1 commit