delta/gitlab/gitlab-ce.git/spec/controllers/admin/groups_controller_spec.rb, branch docs/database-development gitlab.com: gitlab-org/gitlab-ce.git Change all `:empty_project` to `:project` 2017-08-02T21:47:31+00:00 Robert Speicher rspeicher@gmail.com 2017-08-02T19:55:11+00:00 72a7b30c9f363063449b28aa9efc3a26a1752f9f 






Limit non-administrators to adding 100 members at a time to groups and projects
2017-06-06T15:04:26+00:00

Nick Thomas
nick@gitlab.com

2017-06-06T14:55:12+00:00

5c602e306cdf979a70aaa81cd473f491f2eee45a












Refactor Admin::GroupsController#members_update method and add some specs
2017-04-20T16:25:02+00:00

Dmitriy Zaporozhets
dmitriy.zaporozhets@gmail.com

2017-04-20T15:20:30+00:00

bae1644015592c3e432832ec6a0ac07770d46685

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>





Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>







Use `empty_project` where possible in controller specs
2017-01-25T22:14:38+00:00

Robert Speicher
rspeicher@gmail.com

2017-01-25T21:44:33+00:00

4642ca6686d30e1bb203ece4836a294c868a6250












This fixes a long running tests due to changed Sidekiq state
2016-08-15T21:26:40+00:00

Kamil Trzcinski
ayufan@ayufan.eu

2016-08-15T21:26:40+00:00

e8aab1cd1550dd14408ae4c7b51f45110898b949












Fix bug where destroying a namespace would not always destroy projects
2016-08-11T22:36:35+00:00

Stan Hu
stanhu@gmail.com

2016-05-29T02:54:17+00:00

cb8a425ba42e9be23b8712ed29b1db2dcc6bd139

There is a race condition in DestroyGroupService now that projects are deleted asynchronously:

1. User attempts to delete group
2. DestroyGroupService iterates through all projects and schedules a Sidekiq job to delete each Project
3. DestroyGroupService destroys the Group, leaving all its projects without a namespace
4. Projects::DestroyService runs later but the can?(current_user,
   :remove_project) is `false` because the user no longer has permission to
   destroy projects with no namespace.
5. This leaves the project in pending_delete state with no namespace/group.

Projects without a namespace or group also adds another problem: it's not possible to destroy the container
registry tags, since container_registry_path_with_namespace is the wrong value.

The fix is to destroy the group asynchronously and to run execute directly on Projects::DestroyService.

Closes #17893





There is a race condition in DestroyGroupService now that projects are deleted asynchronously:

1. User attempts to delete group
2. DestroyGroupService iterates through all projects and schedules a Sidekiq job to delete each Project
3. DestroyGroupService destroys the Group, leaving all its projects without a namespace
4. Projects::DestroyService runs later but the can?(current_user,
   :remove_project) is `false` because the user no longer has permission to
   destroy projects with no namespace.
5. This leaves the project in pending_delete state with no namespace/group.

Projects without a namespace or group also adds another problem: it's not possible to destroy the container
registry tags, since container_registry_path_with_namespace is the wrong value.

The fix is to destroy the group asynchronously and to run execute directly on Projects::DestroyService.

Closes #17893