different behavior for different kinds of groups (subtypes)

[holtzermann17]

There are some other complexities, i.e. we want different kinds of behavior for different kinds of groups:

• "coauthors": The co-author group of an article. Shouldn't show up in "Groups" list (since it is basically synonymous with, or a simple overlay to, the Articles list). User can request to join, or be added directly by group admin. Note: not every article has more than one "coauthor", and even if you have permission to edit an article, you aren't necessarily a "coauthor" unless you are added to the coauthor group.
• "teams": A collaborative editing group -- all members of the team can edit all articles in the group. This means that in order to add content to a given group, a user needs editing permission for that article. User can request to join, or be added directly by group admin. Note: the "world writable" group is an example of a team: it contains all site members, and all content that has been designated as "world writable".
• "buddy list" : The default group that has editing rights to articles owned by a given user. You can either specify a group of type "buddy list" here, or specify an existing team instead (see above). Two popular examples would be "emptyset" (the default), or "worldwritable".

New teams should show up in the "Everything Else" box, but new coauthor groups and buddy lists should not.

Note: Although they are not "teams", collections are in some ways similar to teams: they just collect content, instead of people+content. See #131 for details on collections.

[holtzermann17]

We added "coauthors", "team", and "buddies" group subtypes in f9daa18 -- we still need to get all of the interactions around these different types set up right. (I've moved other old parts of this ticket into a new UI Cleanup item, namely #144.)

Note: I'm still not 100% clear on whether we actually need a "buddies" subtype or not. In any case, I think we do need to distinguish them in some way, and they should not go into the general-purpose listing of groups if we can help it.

[holtzermann17]

The interactions are there now: the final step is to get the permissions sorted out within the OG backend.

[holtzermann17]

It's worth noting that none of the group code will work properly unless this code is run through devel/php after the profile runs.

[holtzermann17]

In order to set up permissions properly, one needs to use admin/config/group/permissions/node/group -- which suggests to me that if we are going to have different permissions for the different types of groups, we will need to create various Content Types (rather than just using a field to specify the "subtype"). First, let's see if I can get the permissions sorted out for a "generic group".

But, it's also possible to disable the og_field_access module in order to give access to all fields (and we can use some other criteria to provide access to nodes?).

[holtzermann17]

This all seems to be working now.

As a note for the future, if we want to actually have different kinds of permissions (which it turns out we don't need so far) then we should create another group content type (not "subtype"), and revise the logic throughout accordingly. For example, we might want to do this if we were to create fully private collaboration spaces.

I figured out how to tell the difference between "buddy lists" and "teams" when doing the migration from the old site -- just need to test that and commit.

[holtzermann17]

Note: this is the query that is used to get the planetmath groups (ideally we would only import the groups that are actually USED for something: this query leaves us only with groups that are not trivial):

-- first attempt
SELECT * from ( SELECT COUNT( planetmath_group_members.userid ) AS cnt,
planetmath_group_members.groupid
FROM planetmath_group_members
GROUP BY planetmath_group_members.groupid ) as t WHERE t.cnt > 1; 

This improves the above to give us the information we actually need, so it's what we use:

-- second attempt
SELECT t.groupid, pmg.userid, pmg.groupname, pmg.description 
FROM planetmath_groups pmg,
 ( SELECT COUNT( planetmath_group_members.userid ) AS cnt,
   planetmath_group_members.groupid
   FROM planetmath_group_members
   GROUP BY planetmath_group_members.groupid ) as t
WHERE t.cnt > 1
AND pmg.groupid = t.groupid;

We can separate out "default groups" from custom groups by adding another line that checks whether planetmath_groups.description is LIKE or NOT LIKE ''This is the default group for user%'.

-- third attempt
SELECT t.groupid, pmg.userid, pmg.groupname, pmg.description 
FROM planetmath_groups pmg,
 ( SELECT COUNT( planetmath_group_members.userid ) AS cnt,
   planetmath_group_members.groupid
   FROM planetmath_group_members
   GROUP BY planetmath_group_members.groupid ) as t
WHERE t.cnt > 1
AND pmg.groupid = t.groupid
AND planetmath_groups.description LIKE 'This is the default group for user%';

[holtzermann17]

This appears to be working now.