Group system overhaul
Quick glance changes:
- Combined OpenGroup, HiddenGroup and GroupDescription into a single model AuthGroup (includes data migration)
- Improved group security by removing the ability to request groups with the internal flag set.
- Added group membership overview and the ability for group managers to remove members.
- Implemented #504 (closed) Group leaders
- Improved reusability of user state checking
So the group model refactor is probably the biggest single change. There is a data migration, forward and reverse, to make the switch over to the new model (hopefully) completely painless. As always, backup your database before running the migration. OpenGroups have the AuthGroup.open
flag set, HiddenGroups have the AuthGroup.hidden
flag set and GroupDescriptions are migrated into the AuthGroup.description
field. All other groups become requestable except any group that starts with Corp_
, Alliance_
or is the configured Member or Blue group which are flagged as AuthGroup.internal
and won't be requestable by users. Right? Right! Basically after installing you should check the new group membership overview to ensure that the groups are configured the way you expected them to be.
The new admin view for managing groups looks like this:
You can see here the new options for configuring groups. Every group will have an AuthGroup model created automatically when new groups are added and the default is to configure it as an Internal only group. You can also see the new field for adding members as group leaders. Group leaders have the same access to groups they are leaders of as users who have the group_management
permission set, but only on the groups they have access to. i.e. they will have access to Group Management on the front end, but will only be shown and can only manage groups they are leaders of. They also need to be considered members by the user state system. If they don't have a valid main character who is a member they wont have access to manage groups until they do.
The new group membership list:
The user state system I didn't really change much, mainly just moved the decorator tests into a class so that there is a single location these functions are defined. This saves individual apps rolling their own inline state tests (DRY, separation of concerns) and will hopefully make refactoring the state system easier if it happens in future.