Group relations

Initial version...

Important notes:

The type of relation that can be added to a group is constrained by the type of the group. Only virtual groups may have joint relations, only non-virtual groups the other types.
A virtual group is not really a group but a representation of a joint project (or several) between one or more groups. Some virtual groups may have only one parent, in which case means that one of the parts is so unimportant by itself that no group entry exists for it. (Could be that the group has never released anything independently.)
Relations are directional and only one-way adding/editing is supported by the interface (atm). This means that if you want to add a joint relation, for example, you have to add it to/from the virtual group; it is not possible to add it to/from the participating groups. The group relation page (addgroupgroup) will redirect you to the other end of the relation when it is necessary.

Types

Feel free to suggest changes to the description texts and labels. At least the labels on the group page are not very clear atm.

Joint

This group includes the other group. ANBU-AonE -> ANBU

Joint - Participant

This is the most important type of relation because it affects different stats and listings. Using the example group ANBU-AonE:

All stat counters (number of anime/eps/files) and total file size for ANBU will include the files by ANBU-AonE. The same is true for AonE. The stats for ANBU-AonE will of course not include files by released separately by ANBU and AonE.
The anime-group page will list files in the same manner. Naruto-AonE will list the Naruto files by ANBU-AonE and AonE. Naruto-ANBU-AonE will only list Naruto files by ANBU-AonE.
The anime-group status, found in the anime and group pages, will reflect the relation likewise. Naruto-AonE has the state completed while Naruto-ANBU-AonE is dropped. The status of the participating groups should not be dropped unless it is clear that they will never continue in any other form. Inukami-Mendoi-SHS-KAA is an other example of such cases.
The group page will list all releases by a the group + releases by joint projects. An anime entry will only appear once, though.

Important

Only groups marked virtual/joint can have "joint" relations. It is the only relation type such groups can have.

Child/sub/branch

This group is a child of the other group. DB-BR -> DB

Child - Parent

Split/fission

This group split from the other group. Conclave -> A-Keep

Split - Lost

Merge/fusion

This group merged into the other group.

Merge - Merge

This should not be used between the groups that merged, but between each part and the new group.

Rename

This group was formerly known as the other group.

Formerly - Now

Other

This group has some other weak relation to the other group.

Other - Other

Used for loose/weak relations between groups. It should however only be used for real (official) relations and not just for "fun".

Suggestions

Interface

Allow adding both ways.
Better descriptions and labels.
Latest relations.
Filters.
Reports.
Better representation @ group page, a new box only for relations so the info box don't get too big. This problem exists for the anime page (anime relations) too.
Group relation maps?

Expand by group should list the same files as the anime-group page does, maybe.
Group box @ anime page should group joints together, maybe.
Better representation of mylist state @ anime-group box and group page.
Completion bars at group page.

Rights

Normal users have the right to add relations atm. The only problematic relation is joint (since it affects group stats and anime-group relations so much), but since this relation is constrained by the group type it should't be much of a problem. The user have to creq the group type first anyway. The other types have no real meaning (at least not yet) and should therefore not be much of a problem either.