An error occurred fetching the project authors.
- 03 Dec, 2016 1 commit
-
-
Timothy Andrew authored
The models were incorrectly merged (this would have been avoided if !927 was merged in, but that MR is still review) leading to a few spec failures.
-
- 02 Dec, 2016 1 commit
-
-
Valery Sizov authored
-
- 29 Nov, 2016 1 commit
-
-
Timothy Andrew authored
- Extract all common {push,merge} access level model code into the `ProtectedBranchAccess` module - Use the HTTP verb to define controller specs
-
- 17 Oct, 2016 2 commits
-
-
Timothy Andrew authored
(Protected branch access levels)
-
Timothy Andrew authored
1. A protected branch access level `belongs_to` a group in addition to a user. When access for a user is checked, see if the user is present in the access level's group, if any. 2. If a group is added to a project with `:reporter` access or lower, adding a group to a proteted branch does _not_ grant access, since the `push_code` ability is still checked. This is tested with a few hundred new tests in `git_access_spec`.
-
- 20 Aug, 2016 4 commits
-
-
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
-
Timothy Andrew authored
- Primarly whitespace and code style changes. - Improve feature spec dealing with removing a user from a protected branch. Previously, we were only asserting on a "Deleted" flash notice. Now the assertion looks at the database to make sure that the right access level was removed.
-
Timothy Andrew authored
1. Set `gon.current_project_id` in a protected branches controller, since that's the only place this is used. 2. Move flash notice to the redirect message. 3. Rename the `js_access_levels` method to `access_levels_options` 4. Scope a `find` while sending a branch protection email. 5. Use scopes to simplify finding users with push/merge access for a project. 6. Use `change_column_null` to avoid an `ActiveRecord::IrreversibleMigration`
-
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.
-
- 17 Aug, 2016 1 commit
-
-
Douwe Maan authored
Backport changes from gitlab-org/gitlab-ee!581 ## What does this MR do? Backports changes that were made in gitlab-org/gitlab-ee!581, to avoid potential merge conflicts in the future. ## What are the relevant issue numbers? - Related to gitlab-org/gitlab-ee!581 ## Does this MR meet the acceptance criteria? ## Tasks - [ ] !5824 Backport changes from EE!581 to CE - [x] Implementation - [x] ::ProtectedBranches::CreateService.new - [x] Can't remove `load_protected_branches_gon_variables` - [x] `has_many` with count enforced - [x] Extract from access levels - [x] project.protected_branches.create(params) - [x] Improve "access_levels.first" - [x] Fix tests - [x] Fix build - [x] Assign to Douwe - [ ] Wait for review/merge See merge request !5824
-
- 16 Aug, 2016 1 commit
-
-
Timothy Andrew authored
!581 has a lot of changes that would cause merge conflicts if not properly backported to CE. This commit/MR serves as a better foundation for gitlab-org/gitlab-ee!581. = Changes = 1. Move from `has_one {merge,push}_access_level` to `has_many`, with the `length` of the association limited to `1`. This is _effectively_ a `has_one` association, but should cause less conflicts with EE, which is set to `has_many`. This has a number of related changes in the views, specs, and factories. 2. Make `gon` variable loading more consistent (with EE!581) in the `ProtectedBranchesController`. Also use `::` to prefix the `ProtectedBranches` services, because this is required in EE. 3. Extract a `ProtectedBranchAccess` concern from the two access level models. This concern only has a single `humanize` method here, but will have more methods in EE. 4. Add `form_errors` to the protected branches creation form. This is not strictly required for EE compatibility, but was an oversight nonetheless.
-
- 29 Jul, 2016 20 commits
-
-
Timothy Andrew authored
1. Instantiate `ProtectedBranchesAccessSelect` from `dispatcher` 2. Use `can?(user, ...)` instead of `user.can?(...)` 3. Add `DOWNTIME` notes to all migrations added in !5081. 4. Add an explicit `down` method for migrations removing the `developers_can_push` and `developers_can_merge` columns, ensuring that the columns created (on rollback) have the appropriate defaults. 5. Remove duplicate CHANGELOG entries. 6. Blank lines after guard clauses.
-
Timothy Andrew authored
1. It makes sense to reuse these constants since we had them duplicated in the previous enum implementation. This also simplifies our `check_access` implementation, because we can use `project.team.max_member_access` directly. 2. Use `accepts_nested_attributes_for` to create push/merge access levels. This was a bit fiddly to set up, but this simplifies our code by quite a large amount. We can even get rid of `ProtectedBranches::BaseService`. 3. Move API handling back into the API (previously in `ProtectedBranches::BaseService#translate_api_params`. 4. The protected branch services now return a `ProtectedBranch` rather than `true/false`. 5. Run `load_protected_branches` on-demand in the `create` action, to prevent it being called unneccessarily. 6. "Masters" is pre-selected as the default option for "Allowed to Push" and "Allowed to Merge". 7. These changes were based on a review from @rymai in !5081.
-
Timothy Andrew authored
1. Remove `master_or_greater?` and `developer_or_greater?` in favor of `max_member_access`, which is a lot nicer. 2. Remove a number of instances of `include Gitlab::Database::MigrationHelpers` in migrations that don't need this module. Also remove comments where not necessary. 3. Remove duplicate entry in CHANGELOG. 4. Move `ProtectedBranchAccessSelect` from Coffeescript to ES6. 5. Split the `set_access_levels!` method in two - one each for `merge` and `push` access levels.
-
Timothy Andrew authored
1. In the context of protected branches. 2. Test this behaviour.
-
Timothy Andrew authored
1. The model now contains this humanization data, which is the once source of truth. 2. Previously, this was being listed out in the dropdown component as well.
-
Timothy Andrew authored
1. Remove `Project#developers_can_push_to_protected_branch?` since it isn't used anymore. 2. Remove `Project#developers_can_merge_to_protected_branch?` since it isn't used anymore.
-
Timothy Andrew authored
1. The crux of this change is in `UserAccess`, which looks through all the access levels, asking each if the user has access to push/merge for the current project. 2. Update the `protected_branches` factory to create access levels as necessary. 3. Fix and augment `user_access` and `git_access` specs.
-
Timothy Andrew authored
1. Move to dropdowns instead of checkboxes. One each for "Allowed to Push" and "Allowed to Merge" 2. Refactor the `ProtectedBranches` coffeescript class into `ProtectedBranchesAccessSelect`. 3. Modify the backend to accept the new parameters.
-
Timothy Andrew authored
1. Improve error handling while creating protected branches. 2. Modify coffeescript code so that the "Developers can *" checkboxes send a '1' or '0' even when using AJAX. This lets us keep the backend code simpler. 3. Use services for both creating and updating protected branches. Destruction is taken care of with `dependent: :destroy`
-
Timothy Andrew authored
- And hook up their associations.
-
Timothy Andrew authored
1. Instantiate `ProtectedBranchesAccessSelect` from `dispatcher` 2. Use `can?(user, ...)` instead of `user.can?(...)` 3. Add `DOWNTIME` notes to all migrations added in !5081. 4. Add an explicit `down` method for migrations removing the `developers_can_push` and `developers_can_merge` columns, ensuring that the columns created (on rollback) have the appropriate defaults. 5. Remove duplicate CHANGELOG entries. 6. Blank lines after guard clauses.
-
Timothy Andrew authored
1. It makes sense to reuse these constants since we had them duplicated in the previous enum implementation. This also simplifies our `check_access` implementation, because we can use `project.team.max_member_access` directly. 2. Use `accepts_nested_attributes_for` to create push/merge access levels. This was a bit fiddly to set up, but this simplifies our code by quite a large amount. We can even get rid of `ProtectedBranches::BaseService`. 3. Move API handling back into the API (previously in `ProtectedBranches::BaseService#translate_api_params`. 4. The protected branch services now return a `ProtectedBranch` rather than `true/false`. 5. Run `load_protected_branches` on-demand in the `create` action, to prevent it being called unneccessarily. 6. "Masters" is pre-selected as the default option for "Allowed to Push" and "Allowed to Merge". 7. These changes were based on a review from @rymai in !5081.
-
Timothy Andrew authored
1. Remove `master_or_greater?` and `developer_or_greater?` in favor of `max_member_access`, which is a lot nicer. 2. Remove a number of instances of `include Gitlab::Database::MigrationHelpers` in migrations that don't need this module. Also remove comments where not necessary. 3. Remove duplicate entry in CHANGELOG. 4. Move `ProtectedBranchAccessSelect` from Coffeescript to ES6. 5. Split the `set_access_levels!` method in two - one each for `merge` and `push` access levels.
-
Timothy Andrew authored
1. In the context of protected branches. 2. Test this behaviour.
-
Timothy Andrew authored
1. The model now contains this humanization data, which is the once source of truth. 2. Previously, this was being listed out in the dropdown component as well.
-
Timothy Andrew authored
1. Remove `Project#developers_can_push_to_protected_branch?` since it isn't used anymore. 2. Remove `Project#developers_can_merge_to_protected_branch?` since it isn't used anymore.
-
Timothy Andrew authored
1. The crux of this change is in `UserAccess`, which looks through all the access levels, asking each if the user has access to push/merge for the current project. 2. Update the `protected_branches` factory to create access levels as necessary. 3. Fix and augment `user_access` and `git_access` specs.
-
Timothy Andrew authored
1. Move to dropdowns instead of checkboxes. One each for "Allowed to Push" and "Allowed to Merge" 2. Refactor the `ProtectedBranches` coffeescript class into `ProtectedBranchesAccessSelect`. 3. Modify the backend to accept the new parameters.
-
Timothy Andrew authored
1. Improve error handling while creating protected branches. 2. Modify coffeescript code so that the "Developers can *" checkboxes send a '1' or '0' even when using AJAX. This lets us keep the backend code simpler. 3. Use services for both creating and updating protected branches. Destruction is taken care of with `dependent: :destroy`
-
Timothy Andrew authored
- And hook up their associations.
-