summaryrefslogtreecommitdiff
path: root/spec/features/protected_branches_spec.rb
Commit message (Collapse)AuthorAgeFilesLines
* Use `:empty_project` where possible in top-level feature specsrs-empty-project-featuresRobert Speicher2017-04-201-1/+1
|
* Move protected branches access control spec into a shared example.Timothy Andrew2016-08-201-69/+2
| | | | | 1. EE access control specs are significantly different, so this is a way to reduce potential merge conflicts. EE and CE specs go in separate files.
* Backport EE assertions in protected branch related specs.Timothy Andrew2016-08-161-4/+4
| | | | | - Use assertions in the vein of `merge_access_levels.map(&:access_level)` instead of `merge_access_levels.first.access_level`
* Don't select an access level if already selected.Timothy Andrew2016-08-161-4/+12
| | | | | | | | | | | | | | | 1. This is in regard to the protected branches feature spec. 2. For example, if "Masters" is already selected, don't re-select "Masters" during the spec. 3. This is due to a bug in the frontend implementation, where selecting an already-selected access level _deselects_ it, which is something we don't need. I'll create a separate issue for this. 4. This hasn't turned up before, because we were manually creating missing access levels prior to e805a64. Now, we just use nested attributes, and missing access levels fail validation.
* Backport changes from gitlab-org/gitlab-ee!581 to CE.Timothy Andrew2016-08-161-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | !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.
* Wrap param with parens for consistencyAlfredo Sumaran2016-08-051-1/+1
|
* Add custom css class to each dropdown to fix failing specAlfredo Sumaran2016-08-051-3/+3
|
* Update layout and JS for create protected branch.Alfredo Sumaran2016-08-051-4/+4
| | | | Also updates protect branch list
* Use `Gitlab::Access` to protected branch access levels.Timothy Andrew2016-07-291-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Implement review comments from @axil.Timothy Andrew2016-07-291-2/+4
| | | | | | | | 1. Align "Allowed to Merge" and "Allowed to Push" dropdowns. 2. Don't display a flash every time a protected branch is updated. Previously, we were using this so the test has something to hook onto before the assertion. Now we're using `wait_for_ajax` instead.
* Make specs compatible with PhantomJS versions < 2.Timothy Andrew2016-07-291-4/+0
| | | | | 1. These versions of PhantomJS don't support `PATCH` requests, so we use a `POST` with `_method` set to `PATCH`.
* Humanize protected branches' access levels at one location.Timothy Andrew2016-07-291-9/+2
| | | | | | | 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.
* Update protected branches spec to work with the `select`s.Timothy Andrew2016-07-291-0/+75
| | | | | | | | | | 1. Get the existing spec passing. 2. Add specs for all the access control options, both while creating and updating protected branches. 3. Show a flash notice when updating protected branches, primarily so the spec knows when the update is done.
* Use the `GLDropdown` component to select protected branches.Timothy Andrew2016-07-071-1/+3
| | | | | | | | | | 1. Modify the component to support a callback for every key press in the filter. We need this so we can update the "Create: <branch_name" label. 2. Modify the component to use `$(<selector>).first().click()` instead of `$(selector)[0].click()`, because the latter is non-standard, and doesn't work in PhantomJS.
* Add a feature spec for protected branch creation.Timothy Andrew2016-07-051-0/+82
1. Doesn't seem like there's an easy way to do this for the actual branch protection, since we'd have to test an actual `git push`. 2. Testing branch creation the web UI is also not straightforward, since the factory repo doesn't have any hooks, and so access checks at the `gitlab-shell` level aren't run.
View Lorry Controller Status