Commit graph

10 commits

Author SHA1 Message Date
🙈 jacopo beschi 🙉
729f05f0e3 Adds Rubocop rule for line break around conditionals 2018-01-11 16:34:01 +00:00
Rémy Coutable
4af9d592c5 Replace factory_girl_rails with factory_bot_rails
I've followed the [upgrade guide](https://github.com/thoughtbot/factory_bot/blob/4-9-0-stable/UPGRADE_FROM_FACTORY_GIRL.md) and ran these two commands:

```
grep -e FactoryGirl **/*.rake **/*.rb -s -l | xargs sed -i "" "s|FactoryGirl|FactoryBot|"
grep -e factory_girl **/*.rake **/*.rb -s -l | xargs sed -i "" "s|factory_girl|factory_bot|"
```

Signed-off-by: Rémy Coutable <remy@rymai.me>
2017-12-14 15:01:55 +01:00
Eric
fb5b2d8d0e Extending API for protected branches 2017-08-02 10:16:17 +00:00
Lin Jen-Shin
f35563b238 Make access level more compatible with EE
So the behaviour would be similar in CE and EE
2017-07-28 18:55:29 +08:00
Timothy Andrew
dd3b738d5b Fix failing tests relating to backporting ee!581.
1. `GitPushService` was still using `{merge,push}_access_level_attributes` instead
   of `{merge,push}_access_levels_attributes`.

2. The branches API creates access levels regardless of the state of the
   `developers_can_{push,merge}` parameters. This is in line with the UI,
   where Master access is the default for a new protected branch.

3. Use `after(:build)` to create access levels in the
   `protected_branches` factory, so that `factories_spec` passes. It
   only builds records, so we need to create access levels on `build` as
   well.
2016-08-16 13:42:34 +05:30
Timothy Andrew
37651d2f4c Fix the protected branches factory.
1. Previously, we were using `after_create` to create access levels.

2. At the time of protected branch creation, there are _no_ access
   levels present, which is invalid, and creation fails.

3. Fixed by setting access levels before the protected branch is created.
2016-08-16 12:45:48 +05:30
Timothy Andrew
e805a64700 Backport changes from gitlab-org/gitlab-ee!581 to CE.
!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.
2016-08-16 11:05:14 +05:30
Timothy Andrew
0a8aeb46dc Use Gitlab::Access to protected branch access levels.
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.
2016-07-29 15:20:39 +05:30
Timothy Andrew
828f6eb6e5 Enforce "No One Can Push" during git operations.
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.
2016-07-29 15:20:39 +05:30
Robert Speicher
6df45eb463 Move all factory definitions to their own file 2016-03-04 15:26:51 -05:00