Support groups of node types other than 'group'

Moving this to the main Drupal Commons issue queue per #1812492: Consider using central issue queue for Commons projects.

I'm currently working on this functionality. I wanted to leverage some of the great work that's being done for the commons features that are included in the commons distribution but at the time of writing this I need at least three node types that are groups or group content. I found myself overriding so much that I thought I might take a crack at modifying commons_groups (and any features that relate to groups) so that it will handle any node type created as a group or group content. If anyone else has input I'd love to hear it.

Just so it's clear, I didn't start with the distribution but rather wanted to be able to just use the features I choose to in my own site but of course I will develop this as if it belongs within the commons distro.

Thanks

Scott

Thanks for weighing in here - Let us know if we can help you in your efforts to write a patch here!

that it will handle any node type created as a group or group content.

The ultimate goal here is actually to support groups that are non-node entities as well.

Just wanted to post an update for those following...

I posted earlier that I would try and patch the commons_groups module to

handle any node type created as a group or group content

We have had to move away from the Commons distro as our requirements have changed and I don't have the time to try and rework the group structure here. :(

Here is my anaylsis of the current commons codebase:

Hardcoded Node Entity functions

commons_bw:
Built on the node_form, hard coded to load a partial node_form and grab field instances of type node. Most of this module would need to be re-written to give functionality to non-node entities.

Commons_content_moderation:
uses flag 2.x and node to create views for moderated content. Not sure if rewriting is possible with flag 2.x -- you would need to change flag definitions at the least.

commons_featured
Uses a node based view, would not be able to support multiple entity types due to a limitation on views only doing one view per entity.

Commons follow
Can only reference nodes. Entity reference only works per entity type, so everything would have to be a node or another entity. We currently get around this for users by creating duplicate message types for users, but I don't see an end user easily replicating this. You would have to create new flags, views, and messages for each type.

Commons groups
(see below for group CT -- this is just node specific code)
While we use hook_entity_view, we also have node_load and node_access functions within the hook_entity_view function.
All of our groups alter functions are wrapped around the node form.
Field instances for groups are defined here, and all require the node table.
Nearly all og api calls have a hardcoded argument of 'node'

Commons like
Hardcoded for nodes and comments, would have to be rewritten to support other entity types.

commons radioactivity
Hardcoded to node_insert and makes node calls

commons trusted contacts
Hardcoded to only allow node entities be posted by a user. node-$bundle-og_user_group_ref is the field instance.

og 2.x
While OG supports entity group content and groups, the widget does not support selecting more than one group type at a time. You could have group content be different entities, but groups themselves would have to be nodes.

flag 2.x
Had hardcoded to nodes throughout, including node_hooks, etc. Doesn't use the entity api, therefore its relying on node for many of the non-core content.

Lingotek
Hardcoded to nodes. No internationalization would work with lingotek without re-writing.

Hard coded 'group' CT functions

Commons groups specifies the group type specifically for much of its additional functionality (help, node alter functions). If you create a new group CT, most of the wrappers commons adds to groups won't work.

Also, og_node_access is not implemented in an entity agnostic fashion. There is a deep deep rabbit hole you can follow starting here:
https://drupal.org/node/1382252

Thanks, japerry.

From my perspective the next steps here are to be more clear about our potential options are for proposed functionality, and to assess the effort for supporting that functionality.

The proposal here breaks down into two possible features:
Support groups that:

A) Are groups of node types other than 'group'

It seems like Commons can and should support this in 3.x.

B) Are groups of entity types other than 'node' [edited to fix a typo]

It's less clear to me that we should support this, but worth further discussion.

I'd like to update the issue summary with this overview, but first, some discussion:

commons_featured

Uses a node based view, would not be able to support multiple entity types due to a limitation on views only doing one view per entity.

My first thought here as that if we wanted, we could get around that limitation by providing a "featured" block that uses an entity field query...if content other than nodes could be "Featured." Currently, "featured content" is actually the "promoted to frontpage" designation provided by the node module and is specific to node at the core.

I think we'd be fine continuing with the assumption that only nodes need to be featured and if there's a site that requires the ability to feature entities of any type, they could consider using flag to mark these entities.

Similarly for Commons Content Moderation, it seems appropriate to continue with the (core) assumption that "content" typically means "nodes," especially for user-generated content that is subject to moderation.

Commons follow

> Can only reference nodes. Entity reference only works per entity type, so everything would have to be a node or another entity. We currently get around this for users by creating duplicate message types for users, but I don't see an end user easily replicating this. You would have to create new flags, views, and messages for each type.

I think we're talking about a couple of different things here:

Commons follow:
- The ability to flag entities we wish to follow. Flag 2.x supports this ability.

Commons Activity streams:
- The ability to have a "referenced entities" reference field used to join against when build views of user activity. We'd need to create an entity reference field for entities of each type that we'd need to be able to reference and then join against that field when displaying the activity stream view. This seems cumbersome and potentially challenging from a performance standpoint, since that would entail additional JOINs for each entity type contained in the view.

Commons like

Hardcoded for nodes and comments, would have to be rewritten to support other entity types.

True, though it appears that rewriting here might be relatively low in effort.

    $commons_entity_integrations = module_invoke_all('commons_entity_integration');
        if (!empty($commons_entity_integrations['node'])) {
          foreach ($commons_entity_integrations['node'] as $bundle => $options) {

My sense is we could simply iterate over each entity type and bundle and do the same thing for exposing vote-ability to the VotingAPI.

commons trusted contacts

Hardcoded to only allow node entities be posted by a user. node-$bundle-og_user_group_ref is the field instance.

I think there are some clear assumptions in the construction of this feature: Trusted contacts are users and content is nodes, protected by the core node access system. Let's keep these assumptions.

So far, it seems like Commons Featured, Commons Content Moderation, and Commons Trusted Contacts wouldn't have to change under proposals A or B :).

og 2.x

While OG supports entity group content and groups, the widget does not support selecting more than one group type at a time. You could have group content be different entities, but groups themselves would have to be nodes.

I agree that you can only reference one entity type at a time, but I don't understand why groups would have to be nodes in all cases, from the perspective of the Entity Reference field. It is possible through configuration to have certain content or entity types that can are posted into non-node group entities, providing those entities are designated as groups. I think the only limitation is that a single audience field can't be shared across entity types. I don't see that as a clear limitation.

flag 2.x

Had hardcoded to nodes throughout, including node_hooks, etc. Doesn't use the entity api, therefore its relying on node for many of the non-core content.

I think I'm misunderstanding this assertion, since Flag 2.x supports any entity type. Today we define Commons Follow flags for user and node entities, and we can create additional flags for new entity types. Here's the Flag 2.x for creating new Flags, which shows that any entity type defined can be flagged:

commons radioactivity
Hardcoded to node_insert and makes node calls.

This does seem like an area with the most effort required given that we have code that handles transitioning content inside and outside of groups and the resulting impact to radioactivity of the group. However, supporting non-node group entities still seems like a moderate effort, rather than an enormous one.

I guess I should clarify that my post above is things that would have to change. Some of those should be fairly trivial, while other parts wouldn't be as much.

Agreed that we're looking at two issues, potentially three:
A) Are groups of node types other than 'group'
B) Are group content from entity types other than 'node'
C) Are groups of entity types other than node.

First with A) Are of node types other than 'group'?

I do think this would be good to have, and it wouldn't be that hard to give most functionality. OG doesn't really care what the group is, so it would be commons specific. In generalizing any hardcoded assumptions we make in commons_groups, it might be a good idea to look at de-coupling the commons_groups module into OG subfeatures mentioned in #2173561: Split out commons_groups into OG sub modules

It appears that there is only some minor code changes that would be needed to give other groups full access to features we provide in the groups type.

B) Are group content from entity types other than 'node'

The comments in #7 are a good response to the level of work, I was just laying out what would need to change. I think incorporating these features in their own issue would be a good idea

C) Are groups of entity types other than node.
Also not too difficult, although I think would require more than just site-builder expertise. Essentially commons_trusted_contacts demonstrates that you can make groups of entity types other than node.

Speaking of trusted contacts...
There's quite a few assumptions about trusted contacts being enabled and turned on throughout commons. Another potential API feature is expanding the entity integrations functionality to include entity type features. Basically take all of those 'module_exists' functions and replace them with some search for a key and then do whatever that key says.. or make more hook functions that implementing modules could use instead.

The one last related item to this is #2020061, Comment #16, issue #2:
This code snippet relates to finding content a user can post into, and we make an assumption about node and group. (note, og_get_groups_by_user() or og_get_entity_groups() don't work here because the user isn't necessarily a member yet) Certainly, we can change this code -- however it might have a considerable performance impact. I suspect some other modules will have similar performance issues.

I appears that everyone who's commented on this issue from outside the immediate Commons team has expressed a need for proposal A): Groups of node types other than 'group'.

Let's proceed with this proposal and allow proposals B and C to live as another issue and revisit them if we see more demand for those features.

If someone has a more clear title for this issue than the change I'm making here, suggestions are certainly welcome :).

I marked #2086307: Handling multiple Group types as a duplicate of this issue.

Adding to our 3.9 radar.

After further review, we actually act on all og group types, as long as they are a node:

  if ($file->name == 'commons_groups') {
    $group_bundles = og_get_all_group_bundle();
    if (!empty($group_bundles['node'])) {

This code above gets all groups, and then adds fields for groups of entity type node. The commons_groups_entity_types function is just for group content, not groups themselves.

The issue however remains that groups don't get UI help (form alter is too narrow in scope), and we do not provide any views to display content from other group types. It also causes commons_groups to become overridden because the system info function defines fields but no content types.

Okay this is a fairly complex issue, but I've gotten the first part of it complete. The patch included will allow users to create new group types and retain the privacy and other group features found in commons.

However, it will also cause commons_groups to show up as overridden. I'm working to try to resolve that issue, but this patch should be reviewed otherwise to make sure the privacy settings work for everyone (especially if you already have a new group type before this patch, haven't tested that ability yet)

Also, there isn't any changes to the groups views -- not sure where other group types fit in with content displays. The 'groups' button also is specific to the group type, which I'm not certain we should change.

Here is a patch on commons_Groups_pages, which changes how we export panelizer. After talking to stakeholders, I think we're pretty close here, but we need to do more anon vs authenticated vs admins user testing.

There is also some fields missing from the groups (radioactivity and logo) that need to be re-added per the patch in #13

The following slu of patches should enable a site to use any content type as a group. We will need to update the documentation to show developers how to fully integrate their content type within commons.

By default, this patch will give you the privacy settings included with commons. It will not give you the user permissions, comments settings, etc. In order to use these settings (to truly make the group a copy of the stock group included with commons), you must implement a commons_entity_integration_hook like so:

function commons_groups_commons_entity_integration() {
  return array(
    'node' => array(
      'my_group' => array(
        'is_group' => TRUE,
        'is_group_content' => FALSE,
        'exclude_commons_follow' => TRUE,
      ),
    ),
  );
}

Currently, some features are showing as overridden. I'm going to need to consult with Ezra on figuring out resolution to this. Also, in testing these problems, I stumbled upon the title_field error reported here: #2209727: Activity Feed reads as [message:field-target-nodes:0:title_field] The included patch includes a fix for this as well.

Marking as review for others to look over the feature and report back, knowing full well that this will be re-marked as 'needs work' ;)

It would help to include the patch....

Ok - did a quick review of the patch from #16.

applied the patch to Commons 7.x-3.9

Prior to applying the patch, I had an existing additional Group type called "Group2" where I had added the group_access (Group visibility) field via the OG field settings.
This field is hidden in Drupal Commons, so I then added field_og_subscribe_settings and field_og_access_default_value.
Prior to the applying this patch, I could not create a node of type 'Group2'. After the patch, it was possible, but none of the Commons UI for creating posts, etc is available for the new group type.

Then, I created a third group type called "Group3". Again I added the group_access field via the OG field settings.
When I try to create a node of this type (without adding field_og_subscribe_settings and field_og_access_default_value) - I get the following error:

EntityMetadataWrapperException: Unknown data property field_og_subscribe_settings. in EntityStructureWrapper->getPropertyInfo() (line 335 of /Users/jessica.straatmann/Sites/commons-7.x-3.9/profiles/commons/modules/contrib/entity/includes/entity.wrapper.inc).

I then manually added field_og_subscribe_settings and field_og_access_default_value to the Group3 type. After doing so, adding this group type worked.

If adding these two fields is required to have additional group types that use group_access, it seems like they should be automatically added when the group_access field is added.

If adding field_og_subscribe_settings and field_og_access_default_value is required for group_access to work on additional node types, this should be automatic or documented heavily.

This patch should eliminate the overridden features to commons_groups

Tested the new patch in #19

It's now possible to create new group types with group_access. The Commons-specific visibility fields will be added automatically after reverting the commons_group feature (This needs to be done after every group type is added, and all Commons features need to be reverted for additional functionality to work.)

The visibility settings work as expected when adding content associated with the new group types.

Note that for the commons tabs (related to adding posts, etc) to be visible on the new group types, comments must be disabled and panelizer must be enabled on the group type.

Thanks, japerry & jastraat!

Note that for the commons tabs (related to adding posts, etc) to be visible on the new group types, comments must be disabled and panelizer must be enabled on the group type.

Since we're doing some Panelizer configuration in this patch, why not also enable Panelizer as a default and disable comments on group nodes? It seems like those are two defaults that site builders would reasonably expect on most sites.

To do a functional review here, could we see some scratch documentation that would explain how to setup a new group type with Commons according to the approach in this patch?

It looks like we've defined a new "'is_group_content' => TRUE," parameter. What are the implications of this API change on upgrading sites with custom content types? Will their custom content types still work?

+        //

Double slash with no comment text.

+    // Don't alter the group panel.

Why not? In general, it's as if not more important to explain the "Why" in code comments as it is to explain the "how."

I think we're close here. Marking as "needs work" pending the above.

We definitely need to define documentation on how to create groups on docs.acquia.com, but I think thats another issue. As for those code pieces, they were commented out code that aren't in the final version.

Also, talking to Jess and others, comments weren't removed by default, but panelizer is already enabled and working by default as well. There isn't a reason why people would want to comment on groups, thats what group content is for. We shouldn't be encouraging bad behavior (comments on the group itself).

Marking as needs review for process, but pretty sure we're good to go here =)

Here is the documentation we've talked about internally.

There are whats considered 'basic' additional groups, and 'commons integrated' additional groups.

All groups have the following features:

• Privacy Settings
• Ability for content to be posted to them
• Comments disabled
• Content page view (when you goto the group it'll show content linked to that group)
• Message subscribe integration

Groups that have full entity integration also gain

• Global User permissions similar to the commons group type
• Unpublished is by default
• Group roles are assigned to the group.

When creating a new content type, its important to revert these three features: commons_groups, commons_groups_pages, commons_topics

You can do this be navigating to admin->structure->features
Alternatively you can type in this drush command:
drush fr -y commons_groups commons_groups_pages commons_topics

To get commons group entity integrations, you must create a module to contain your group (probably easiest to do this as a new feature). When you create this module, you need to add a hook similar to this:

function MYMODULE_commons_entity_integration() {
  return array(
     'node' => array( 
          'MY_CONTENT_TYPE' => array( 
              'is_group' => TRUE,
              'is_group_content' => FALSE,
              'exclude_commons_follow' => TRUE,
             ),
       ),
    );
}

Insert this code before reverting features, otherwise you'll have to revert again for the changes to take affect.

Note, existing types: While your content type may change, the settings on existing nodes will not. Any custom types made before this update will need to be manually updated to reflect the newest changes with this version of commons.

Also, the 'is_group_content' flag isn't required, but is helpful for verbosity sake. By default if you do not include the option, commons will assume your content is group content. (unfortunate, but changing now will be an API change)

The patch above cleans up the code in #21 and clarifies that comments get removed by default when creating a group content type (but not the content itself since an admin may want for some reason to enable them)

Thanks, japerry! This looks nearly RTBC. Reviewing #23 I saw something I missed in earlier reviews - Sorry about that:

+
+/*
+ * Returns an array of entity types that are defined as a group
+ */
+function commons_groups_get_groups() {

Given the return value here, seems like this should be called commons_groups_get_group_types() (and format function documentation per the coding standards for comment escaping and periods at ends of comments).

One thing that seems potentially confusing about the way Commons handles groups: How would we define the criteria for when to use this function versus og_get_all_group_bundle()?

Ok - reviewed this latest patch. Comments are now disabled by default and panelizer is enabled by default. Yay!

The main problem at this junction is that the commons_groups feature will not revert completely.

Okay this patch tackles #25 and #26, both very relevant concerns.

One thing that seems potentially confusing about the way Commons handles groups: How would we define the criteria for when to use this function versus og_get_all_group_bundle()?

When a component is being defined as a field that is going to be used globally in commons (like privacy settings), they are set for all groups using og_get_all_group_bundle. At first it seems like comments wouldn't fit this, but because we're also setting panelizer settings by default (to show views, tabs, etc), comments need to be included in this scope as well.

However, when a setting could be different between the groups, and commons_groups offers a default, it should be set from the feature using the entity_integrations, for example:

This allows someone to make groups with different permissions, published vs unpublished, etc than the default groups type without having to do funky code to alter the feature.

Thanks for the reviews, its up and live!

http://drupalcode.org/project/commons.git/commit/4eed3a3