Group Management System
A need exists to let users manage their own user groups. At present a forum administrator is needed to add or modify groups. This is not optimal.
A web system needs to be made that allows a user to register an "organization" and manage a number of user groups tied to that organization.
- Organization: organizations are unique name spaces that are registered by a single user. The contain a number of user groups. An organization may be a game server, a group or network of servers, or a league.
- User Group: user groups contain a list of users that are members of the group, they are managed by a group moderator.
- Founder: the user who registers an organization and can add co-founders and can create/change/delete groups
- Managers: the users that are assigned to a group and can add/remove/approve/deny users for that group.
This describes a desired implementation.
A web page system should be created that allows users to create and manage organizations. Organization must have unique names. If an organization name exists at creation time, the user requesting the new organization should be notified that the name is unavailable. A user should not be able to create an organization that has the same name as any user other than himself. Organizations must keep a link to their founder account, so that we have a contact e-mail for the organization. The founder can add additional co-founders that can do everything except add/remove the founder and other co-founders.
Organization administrator can create any number of user groups. User group names need to only be unique in the organization they belong to. User groups can have any number of members, pulled from the BZFlag user database. The group membership should store the BZID of the user to allow for name changes. Founders should be able to create, destroy, and rename user groups.
Groups should also have a description field that can be edited by any founder, to identify the group. All members of the group should be able to see this description. When a user is added to a group they should be notified as well. Groups shall be either private or public. A private group is one where only members of that group can see the group and its members. A public group is one in which the group and the names of its members are visible to all.
Groups shall also have a 'membership policy' setting which determines how new members can join the group. There will be three options for the membership policy. An Open group is one in which anyone can join, and a Closed group is one in which only the Founder or one of the groups managers can add new members. The third option is 'By Request', which means that any user can request to be a member of the group, and if they are a member then they can remove themselves at any time. A Founder or group manager must Approve or Deny a request to join a 'By Request' group.
For more details on the requirements of the Group Management System see Group management system functional requirements
Local Server Setup
All groups from the local server will be handled in the format of OrganizationName.UserGroupName. This will fit our current naming convention.
The list server will parse the organization and user group names out of the group requests, and process them as it does now, pulling data from the new system.
A reserved organization should have global administration permissions, to manage all organizations and user groups if needed
- BZFlag: this organization is for global management of the system.
- Developers: this organizations is for developers.
- Local: this organization is reserved for local server groups and should not exist.
Conversion From phpbb Groups
The existing user groups on BZBB are already mostly in the SERVER.GROUP format. We should be able to convert each server into an organization and assign it an owner. The few groups that are left over should be able to be manually ported to the new system. Since the names of most groups will not change, game servers will still work with the new system.
There will be a few difficulties in this process. First, there are already several groups using the BZFLAG organization. If that organization is intended to be reserved, that will need to be handled first.
The second issue will be handling groups with multiple leaders, or organizations that don't have a consistent set of leaders (as in, ORG.GROUP1 and ORG.GROUP2 have leaders that do not overlap). This probably won't be a huge issue for most organizations, but it will still be something that has to be handled.