Change Details

Similarly to core's `UserGroupAssignmentService`, the `GlobalGroupAssignmentService` should evaluate user requirements conditions when determining what groups can and cannot be assigned to the given user. Since the conditions are evaluated against `UserIdentity`, the local identity of the target global user should be passed to the condition checker. This local identity should be from the current wiki. This approach will enable checking conditions for global group assignments without the need to maintain a second set of condition handlers, operating on `CentralAuthUser`s. A side-effect of that scenario is that global group conditions might take into account local user properties (which are different for different wikis), but – in principle – we can't protect site admins from setting a non-sense configuration of their site, so this risk is probably acceptable. It's similar to possibility of setting logal group conditions, which only make sense for autopromotion (such as user's IP). === Acceptance criteria - [ ] Trying to add an ineligible user to a restricted global group fails.

Similarly to core's `UserGroupAssignmentService`, the `GlobalGroupAssignmentService` should evaluate user requirements conditions when determining what groups can and cannot be assigned to the given user. Since the conditions are evaluated against `UserIdentity`, the local identity of the target global user should be passed to the condition checker. This local identity should be from the current wiki. This approach will enable checking conditions for global group assignments without the need to maintain a second set of condition handlers, operating on `CentralAuthUser`s. A side-effect of that scenario is that global group conditions might take into account local user properties (which are different for different wikis), but – in principle – we can't protect site admins from setting a non-sense configuration of their site, so this risk is probably acceptable. It's similar to possibility of setting logal group conditions, which only make sense for autopromotion (such as user's IP). === Acceptance criteria - [x] Trying to add an ineligible user to a restricted global group fails.

Similarly to core's `UserGroupAssignmentService`, the `GlobalGroupAssignmentService` should evaluate user requirements conditions when determining what groups can and cannot be assigned to the given user. Since the conditions are evaluated against `UserIdentity`, the local identity of the target global user should be passed to the condition checker. This local identity should be from the current wiki. This approach will enable checking conditions for global group assignments without the need to maintain a second set of condition handlers, operating on `CentralAuthUser`s. A side-effect of that scenario is that global group conditions might take into account local user properties (which are different for different wikis), but – in principle – we can't protect site admins from setting a non-sense configuration of their site, so this risk is probably acceptable. It's similar to possibility of setting logal group conditions, which only make sense for autopromotion (such as user's IP). === Acceptance criteria - [ - [x] Trying to add an ineligible user to a restricted global group fails.