-
- Downloads
Fix Members Activate and Await Service
It's possible for membership records to be invalid when the inherited `access_level` is higher. When using the state machine to transition between membership states, it would validate the records and therefore fail to change the state. To prevent this bug from happening we skip the validation by using `update_all`. To still guarantee valid data, we moved the validation and restrictions to the `Members::ActivateService` and `Members::AwaitService`. * We now call `UserProjectAccessChangedService` when setting a member to be `awaiting`, which runs otherwise as an `after_commit` hook. * We check the free user cap limits when activating a user. * We prevent the last owner to be set to awaiting. * We don't allow a user to set themselves to be `awaiting` anymore.
Showing
- ee/app/models/ee/member.rb 1 addition, 8 deletionsee/app/models/ee/member.rb
- ee/app/models/ee/namespace.rb 7 additions, 0 deletionsee/app/models/ee/namespace.rb
- ee/app/services/members/activate_service.rb 21 additions, 11 deletionsee/app/services/members/activate_service.rb
- ee/app/services/members/await_service.rb 8 additions, 6 deletionsee/app/services/members/await_service.rb
- ee/spec/models/ee/namespace_spec.rb 33 additions, 0 deletionsee/spec/models/ee/namespace_spec.rb
- ee/spec/services/members/activate_service_spec.rb 203 additions, 0 deletionsee/spec/services/members/activate_service_spec.rb
- ee/spec/services/members/await_service_spec.rb 84 additions, 30 deletionsee/spec/services/members/await_service_spec.rb
- locale/gitlab.pot 12 additions, 0 deletionslocale/gitlab.pot
Please register or sign in to comment