Commit Graph

17 Commits

Author SHA1 Message Date
blackst0ne 27c95364b5 Replace '.team << [user, role]' with 'add_role(user)' in specs 2017-12-22 19:18:28 +11:00
Robert Speicher 9513bd18c4 Ensure all project factories use `:repository` trait or `:empty_project` 2017-08-01 14:51:52 -04:00
Rémy Coutable cddc5cacfb Use described_class when possible
Signed-off-by: Rémy Coutable <remy@rymai.me>
2017-07-27 14:31:53 +02:00
Rémy Coutable ddccd24c13 Remove superfluous lib: true, type: redis, service: true, models: true, services: true, no_db: true, api: true
Signed-off-by: Rémy Coutable <remy@rymai.me>
2017-07-27 14:31:53 +02:00
Sam Rose 1ebd9dad8e Add confirm delete protected branch modal 2017-05-08 07:41:58 +00:00
Pawel Chojnacki 19edeba8e3 Prevent people from creating branches if they don't have persmission to push 2017-04-28 16:05:00 +02:00
James Edwards-Jones 07d7d8e659 Renamed ProtectedTag push_access_levels to create_access_levels 2017-04-04 03:38:58 +01:00
James Edwards-Jones f9e849c076 Cleaned up duplication with ProtectedRefAccess concern 2017-04-04 02:59:37 +01:00
James Edwards-Jones 1e15444ae6 Cleanup & tests for UserAccess#can_create_tag? 2017-04-04 02:05:42 +01:00
Pawel Chojnacki eb9b964054 Allow creating protected branch when it doesn't exist
if user has either push or merge permissions

+ Change log entry for fix to creating a branch matching a wildcard fails
2017-01-13 10:53:59 -05:00
tiagonbotelho 482d7802cc changes default_branch_protection to allow devs_can_merge protection option aswell 2016-08-04 21:15:26 +01:00
tiagonbotelho edc5f4018e developer cannot push to protected branch when project is empty or he has not been granted permission to do so 2016-08-02 04:17:32 +01:00
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
Rémy Coutable 2cf7f09b1e
Revert "Revert "Merge branch '18193-developers-can-merge' into 'master' ""
This reverts commit 530f5158e2.

See !4892.

Signed-off-by: Rémy Coutable <remy@rymai.me>
2016-07-18 10:16:56 +02:00
Robert Speicher 530f5158e2 Revert "Merge branch '18193-developers-can-merge' into 'master' "
This reverts commit 9ca633eb4c, reversing
changes made to fb229bbf79.
2016-07-13 13:57:30 -05:00
Timothy Andrew bb81f2afc1 Implement last round of review comments from !4892.
1. Fix typos, minor styling errors.

2. Use single quotes rather than double quotes in `user_access_spec`.

3. Test formatting.
2016-07-13 14:18:05 +05:30
Timothy Andrew 60245bbe22 Refactor `Gitlab::GitAccess`
1. Don't use case statements for dispatch anymore. This leads to a lot
   of duplication, and makes the logic harder to follow.

2. Remove duplicated logic.

    - For example, the `can_push_to_branch?` exists, but we also have a
      different way of checking the same condition within `change_access_check`.

    - This kind of duplication is removed, and the `can_push_to_branch?`
      method is used in both places.

3. Move checks returning true/false to `UserAccess`.

    - All public methods in `GitAccess` now return an instance of
      `GitAccessStatus`. Previously, some methods would return
      true/false as well, which was confusing.

    - It makes sense for these kinds of checks to be at the level of a
      user, so the `UserAccess` class was repurposed for this. The prior
      `UserAccess.allowed?` classmethod is converted into an instance
      method.

    - All external uses of these checks have been migrated to use the
      `UserAccess` class

4. Move the "change_access_check" into a separate class.

    - Create the `GitAccess::ChangeAccessCheck` class to run these
      checks, which are quite substantial.

    - `ChangeAccessCheck` returns an instance of `GitAccessStatus` as
      well.

5. Break out the boolean logic in `ChangeAccessCheck` into `if/else`
   chains - this seems more readable.

6. I can understand that this might look like overkill for !4892, but I
   think this is a good opportunity to clean it up.

    - http://martinfowler.com/bliki/OpportunisticRefactoring.html
2016-07-13 13:24:56 +05:30