Change Details

Turns out logic for managing global groups is scattered across static methods in `CentralAuthUser`, `WikiSet` and private methods in `SpecialGlobalGroupPermissions`. Factor those into a new service `GlobalGroupStore`. Note that "existence" of global groups is not actually stored in database, they "exist" if they are assigned rights. In addition, they might have an entry in global_group_restrictions which restricts them to a wiki set. This makes things more complicated.

Turns out logic for managing global groups is scattered across static methods in `CentralAuthUser`, `WikiSet` and private methods in `SpecialGlobalGroupPermissions`. Ideally those would be managed by some service (such as `GlobalGroupStore`/`GlobalGroupLookup`) Note that "existence" of global groups is not actually stored in database, they "exist" if they are assigned rights. In addition, they might have an entry in global_group_restrictions which restricts them to a wiki set. This makes things more complicated.

Turns out logic for managing global groups is scattered across static methods in `CentralAuthUser`, `WikiSet` and private methods in `SpecialGlobalGroupPermissions`. FactorIdeally those into a newwould be managed by some service (such as `GlobalGroupStore`.`/`GlobalGroupLookup`) Note that "existence" of global groups is not actually stored in database, they "exist" if they are assigned rights. In addition, they might have an entry in global_group_restrictions which restricts them to a wiki set. This makes things more complicated.