Allow users to create content outside of groups

If it is possible to post content outside groups, this patch helps showing the right counts for content on the quicktab widgets.

diff --git a/profiles/commons/modules/contrib/commons_bw/commons_bw.module b/profiles/commons/modules/contrib/commons_bw/commons_bw.module
index dc40428..fadf675 100644
--- a/profiles/commons/modules/contrib/commons_bw/commons_bw.module
+++ b/profiles/commons/modules/contrib/commons_bw/commons_bw.module
@@ -329,6 +329,10 @@ function commons_bw_generate_group_widget($group = NULL) {
       if ($group) {
         $view->set_arguments(array($group->nid));
       }
+      else {
+        unset($view->display_handler->options['arguments']);
+        unset($view->display_handler->options['filters']['group_type']);
+      }
       $view->display_handler->options['filters']['flagged']['value'] = 'All';
       $view->get_total_rows = TRUE;
       $view->execute();

It elimantes everything related to a group - if no group exists - which is the case on the homepage.

Yes please! We had this option before, but with the upgrade to 3.4, this became impossible. I'm tempted to call this a bug instead, as it posting site-wide content was available before.

Updated the original issue to summarize how to approach tackling this issue. Interestingly, site builders can already allow users to post site-wide by tweaking permissions and the view. But there are some missing UX issues here, which I've summarized in the resolution above.

This also affects subgroups. It seems this is the same issue or related. To use subgroups, we add a field for parent group in the Group content type:

Administration > Structure > Content types > Group > Edit > Organic Groups

To do this, for the Group type, we check "Group content", in addition to the default "Group", so that a new "Groups audience" field to choose parent group is automatically created. It seems that only group content can have a parent group.

This is suggested for example in this interesting article:

Any type of entity can belong to a group. In fact, the group entities themselves can also be designated as potential content for other groups. If set up this way we could have groups that contain other groups, creating subgroups.
Organic Groups for Drupal 7 | Lullabot

This works really well for plain Organic Groups without Commons. However, currently for Drupal Commons with OG, if there is an empty "Groups audience" (parent) field, that is to say creating a top tree level group without parent, Commons doesn't allow what plain OG does allow, saying:

Please enter one more groups where this content will be posted.

More details on this problem:

#1345212: D7 How to create a subgroup?

Please, is there any known workaround for this? Thank you very much.

@ezra-g - First, since I've written here just sometimes these years, let me take the opportunity to say thanks for all your great work all this time.

Let me explain, I think it's the same problem indeed: Creating group content outside a group worked well in Commons before, like in plain Organic Groups now, but is not working since Commons 7.x-3.4 (October 17, 2013). This is the point.

Now, outside groups, from example the homepage, we can still create content with the content type "Page" (not "group content"), but for example not with the content type "Event" ("group content").

This problem affects the following Commons' content types, all of them set as "group content". They are now confined within groups and can't be created sitewide:

• Answer
• Event
• Group in a tree
• Poll
• Post
• Question
• Wiki

And it doesn't affect the following Common's content types, both of them not set as "group content". They work well sitewide, as always:

• Default Group
• Page

About the relation with the subgroups case, in order to create a tree of parent-child groups, in Organic Groups and therefore in Drupal Commons, as explained by the Lullabot article, groups are set as "group content", to have a before optional "Groups audience" (parent) field, as explained in the previous post. From here this is an especially affected content type, since the top level groups are outside other groups in the tree.

Update: I had tested only stable releases, but now I've just tried a little bit with the latest Commons 7.x-3.6+12-dev, and if I'm not wrong this seems to be working well now, with all content types, although most of them still "group content" as always, being optionally created within groups and also sitewide.

It seems you or your team did recently something about it. Thank you very much!

The frontpage is becoming more complicated than I originally thought, this is mainly due to some permissions issues...

Currently, the BW Widget requires you to either a) have access to the og group you belong to (if its being shown on a group page) or b) have sitewide permission (home page). Because we by default use the global permissions to see if you can post inside a group, then validate if you actually can post inside a group with the validate function, it gets a little wonky.

I don't believe people actually manually type in the group they're trying to post to from the home page. Please someone correct me if I'm wrong, but on most other collaboration software, people expect to go first to the group, then post.

Therefore, I propose that we remove the ability to post to individual groups from the home page, and reserve that for sitewide posts or trusted contacts (personal) posts. If we don't do this, the downside is all authenticated users, even if they cannot post to any groups (or themselves if trusted contacts is disabled) they will still see the form. We also would need to place an additional check for Anonymous users to make sure they don't get the post form.

japerry: people want to share posts in several groups at the same time. Doing so from the homepage makes sense. Or we would also need to change the interface from within the group (Share on other groups: []). I understand the downside, but this can be tackled by only showing the form if users have groups to post to.

First patch to change the view and inform users... working next on trusted contacts and how we deal with permissions around posting as yourself, to groups, and sitewide.

Well, the main glitch was that admins recently could not create content such as events, posts, or sub-group capable top-level groups, outside groups, excepting with some workaround. As said, I tested last dev (I think) as admin very quickly and it seemed solved now for admins, if I wasn't wrong about the tested version -I'm often in a hurry-. That fix is probably enough for most sites, like in our case.

About what you are trying now, if admins can give permissions to some other users to do the same, I guess that's possibly the icing on the cake for some other sites. Thank you as always for all your good work.

[Note] The current workaround (until a stable fix) that I've mentioned is: With a group content type like the default group, which is not set as group content, create a temporary unpublished group for a minute. Post the content within that group. Then remove the temporary parent group. It is content outside groups now. Naturally if later we need to change the content configurarion, we create the temporary parent group for a minute again, to be able to save the configuration form. But usually configuration changes are not needed.

The following patch is a fairly big re-write... in it:

Introduced a new API call for adding options to the group_audience_type form element that was introduced in commons_trusted_contacts.
Moved the group_audience_type from commons_trusted_contacts into commons_groups
Added logic around when we show the bw form, and set permissions for sitewide, group posting, and trusted contacts posts.

After writing test scenarios in general for Commons, I'll come back and write cases for this. Until then, please review and see if this works! Really interested in permissions feedback, as we're changing the way commons uses global permissions in respect to posting content.

Also, we need to decide what roles should have default site-wide access.

After discussing the patch with Jakob and testing it out against a new Commons install it looks like everything is working great.

I also did a patch review and came up with mostly minor suggestions for improving coding standards, unused variables, clutter, etc.

1. +++ b/modules/commons/commons_bw/includes/views/handlers/commons_bw_handler_node_partial_form.inc
   @@ -25,16 +25,36 @@ class commons_bw_handler_node_partial_form extends views_handler_area {
   +    global $user;
   

   This would unnecessary if one of the OG API functions is used. (see next comment)

2. +++ b/modules/commons/commons_bw/includes/views/handlers/commons_bw_handler_node_partial_form.inc
   @@ -25,16 +25,36 @@ class commons_bw_handler_node_partial_form extends views_handler_area {
   +    // Homepage, check to see if user can post to any groups
   +    $query = new EntityFieldQuery();
   +    $query->entityCondition('entity_type', 'node')
   +      ->entityCondition('bundle', 'group')
   +      ->propertyCondition('status', 1)
   +      ->addMetaData('account', $user);
   +    // Run the query as the current user.
   +    $result = $query->execute();
   

   It would be better to use the og_get_groups_by_user() or og_get_entity_groups() API functions here to retrieve the user's groups.

3. +++ b/modules/commons/commons_bw/includes/views/handlers/commons_bw_handler_node_partial_form.inc
   @@ -25,16 +25,36 @@ class commons_bw_handler_node_partial_form extends views_handler_area {
   +      if (og_user_access('node', $gid, "create $bundle content")) {
   
   +++ b/modules/commons/commons_groups/commons_groups.module
   @@ -396,6 +408,15 @@ function commons_groups_form_alter(&$form, &$form_state, $form_id) {
   +function commons_groups_form_node_type_form_alter(&$form, &$form_state) {
   +  if(isset($form['og']['og_group_content_type'])) {
   +    // Don't show the settings, as there might be multiple OG audience fields
   +    // in the same bundle.
   +    $form['og']['og_group_content_type']['#description'] .= '<br />' .
   +      t('To allow posting of content outside of a group, set the related create/edit/delete !permissions for this content type', array('!permissions' => l(t('user permissions'), '/admin/people/permissions')));
   +  }
   +}
   +
   

   I've seen a few posts (https://drupal.org/comment/7842115#comment-7842115) mentioning that non-node entity group types would ideally be supported.

   To support any entity type, you could do something like:

   $user_groups = og_get_groups_by_user();
   
   $groups = og_load_multiple($user_groups);
   
   $entities = array();
   foreach ($entities as $entity) {
     $entities[] = entity_load($entity->entity_type, $entity->etid);
   }
   

4. +++ b/modules/commons/commons_bw/includes/views/handlers/commons_bw_handler_node_partial_form.inc
   @@ -25,16 +25,36 @@ class commons_bw_handler_node_partial_form extends views_handler_area {
   +    if(!module_exists('commons_trusted_contacts') && empty($ids)) {
   

   If having the commons_trusted_contacts module enabled is required for proceeding, then I'd suggest bailing out with the checks for anonymous users and users without access before running the expensive checks for determining if a user can post to any groups.

5. +++ b/modules/commons/commons_groups/commons_groups.module
   @@ -6,6 +6,15 @@
   +/*
   + * Hook commons_groups_context_toggle.
   + * $form and $form_state can be used to get better context around if the option
   + * should be shown on the form or not.
   + */
   +function hook_commons_group_context_toggle_options(&$options, $form, $form_state) {
   +  $options[] = array('sitewide' => t('Post site-wide'));
   +}
   +
   

   If this is an example of how to use the commons_groups_context_toggle hook then I'd suggest putting it into a commons_groups.api.php file.

6. +++ b/modules/commons/commons_groups/commons_groups.module
   @@ -396,6 +408,15 @@ function commons_groups_form_alter(&$form, &$form_state, $form_id) {
    
   +function commons_groups_form_node_type_form_alter(&$form, &$form_state) {
   

   Could use a docblock.

7. +++ b/modules/commons/commons_groups/commons_groups.module
   @@ -861,6 +881,88 @@ function commons_groups_first_contribution($account, $node) {
    
   +function commons_groups_commons_group_context_toggle_options($form, $form_state) {
   

   Could use a docblock.

8. +++ b/modules/commons/commons_groups/commons_groups.module
   @@ -861,6 +881,88 @@ function commons_groups_first_contribution($account, $node) {
   +  global $user;
   

   $user isn't used anywhere.

9. +++ b/modules/commons/commons_groups/commons_groups.module
   @@ -861,6 +881,88 @@ function commons_groups_first_contribution($account, $node) {
   +function commons_groups_form_commons_bw_partial_node_form_alter(&$form, &$form_state) {
   +  if (!empty($form_state['group_id'])) {
   +    return;
   +  }
   +
   +  commons_groups_form_add_group_context_toggle($form, $form_state);
   +  $form['#validate'][] = 'commons_groups_partial_node_form_validate';
   +
   +}
   +
   +function commons_groups_form_node_form_alter(&$form, &$form_state) {
   +  commons_groups_form_add_group_context_toggle($form, $form_state);
   +  $form['#validate'][] = 'commons_groups_partial_node_form_validate';
   +}
   

   Could use docblocks.

   This could also be compacted a bit by implementing hook_form_alter and adding the toggle and validation if the form ID matched either commons_bw_partial_node_form or node_form.

10. +++ b/modules/commons/commons_groups/commons_groups.module
    @@ -861,6 +881,88 @@ function commons_groups_first_contribution($account, $node) {
    +  $options = module_invoke_all('commons_group_context_toggle_options', $form, $form_state);
    

    The common naming convention for hooks that provide information is to end the hook name with "_info".

    It would be nice to also have an associated alter function in case anyone wants to change the available toggle options.

11. +++ b/modules/commons/commons_groups/commons_groups.module
    @@ -861,6 +881,88 @@ function commons_groups_first_contribution($account, $node) {
    +    '#weight' => 70,
    

    This is redundant with the weight set below. Unless og_group_ref isn't always set, in which case the code that shows the form item under the group toggle should check for the existence of $form['og_group_ref'] before attempting to use it and this default weight can be kept.

12. +++ b/modules/commons/commons_groups/commons_groups.module
    @@ -861,6 +881,88 @@ function commons_groups_first_contribution($account, $node) {
    +    form_set_error(OG_AUDIENCE_FIELD, t('Please enter one more groups where this content will be posted. groups'));
    

    The word " groups" at the end of the sentence can be removed.

13. +++ b/modules/commons/commons_trusted_contacts/commons_trusted_contacts.module
    @@ -879,42 +879,37 @@ function commons_trusted_contacts_form_commons_bw_partial_node_form_alter(&$form
    + * Implements hook_commons_group_context_toggle_options
    

    This could also be moved to commons_groups.commons_groups.inc if hook_commons_groups_context_toggle_options was declared in a hook_hook_info().

    Also the comment could follow doxygen standards.

14. +++ b/modules/commons/commons_trusted_contacts/commons_trusted_contacts.module
    @@ -879,42 +879,37 @@ function commons_trusted_contacts_form_commons_bw_partial_node_form_alter(&$form
    +  $trusted_contacts_toggle = FALSE;
    

    $trusted_contacts_toggle = FALSE; could be set in an "else" below so it isn't initialized unnecessarily in case the entity isn't a commons group.

15. +++ b/modules/commons/commons_trusted_contacts/commons_trusted_contacts.module
    @@ -922,6 +917,7 @@ function commons_trusted_contacts_form_add_privacy_toggle(&$form, &$form_state)
    +  global $language;
    

    I'm not sure I see where $language is used here.

Thanks Devin for the review! Here are some responses and a patch.

#1, #2 and #3: We cannot do this. We're trying to get -all- groups that are 'accessible' by a user. This doesn't mean that they are a member. I looked at using those functions first, but when you see it joins the og_membership table, its not applicable for this use case.
In the case of #3, we would need to write some more, albeit expensive, functions to grab all content, not just nodes. Since much of commons is already hardcoded to the context of nodes, I suggest we tackle that as another issue, perhaps in #1792644

#4: we already bail out in the code for anonymous users and those without global access.
#5: Done, good idea.
#8: ahh yes, like language in #15, I was trying some different API functions that required those variables. Removed.
#9: The hook_Form_alter was getting really large, but I noticed another bug in this code, and adding these to the form_alter makes sense to avoid duplication and potential for bugs.
#10: Renamed the form field options to commons_group_audience_type_info, to reflect the name of the form field.
#11: While it might seem good to use og_group_ref as the weight (the form alter requires og_group_ref to exist in order to show this widget), you could possibly run into an issue if groups were re-ordered on a site and they were sequential. IE: field A, og_group_ref, field B. one would be -9, then -8, and -7. If you used og_group ref, it'd be -9, -7, -7, -8 (where -8 is the new group_audience_type field). Since in commons we always want the group toggle to be at the bottom, we just hardcode it to 70 (previous code). It probably would be good to look at in another issue if people want to re-order the weight of the edit form.
#13: Could use hook_hook_info, but it seems a bit much for one function to me.

Hopefully that clears things up, other documentation and things I didn't include in the rough draft are now here. Still haven't addressed what to do with default sitewide permissions, but I think we decided that authenticated users would not be able to post sitewide by default.

Here is a patch, marking as needs work. I tried playing with the JS for a bit, but ran into a bug near the end of the workday where if a user has access to one CT but not another, the JS gets executed because its a QT not a new page for the BW widget.

Sitewide content was pending the ability to post outside of node types. However, this approach might be very difficult for 7.x-3.x. See #1792644: Support groups of node types other than 'group' for more info.

I just tested this code and it works great! I was just in the process of hacking up a workaround to allow site-wide posting and found this issue on a random google. Love how y'all are always one step ahead!

I did come across one minor issue. The function commons_bw_partial_node_form_validate() includes a test that prevents the "Post site-wide" option from working unless both commons_trusted_contacts and og_access are enabled. When trying to post without commons_trusted_contacts enabled using "Post site-wide" the user sees the error message, "Please enter one or more groups where this content will be posted."

I'd think we would want to allow site-wide posts with or without commons_trusted_contacts? I'm not sure I understand all the implications but perhaps we might remove this validation handler completely?

Can I please ask, is this feature now available in version 3.9?

This is a very desirable option, as the "trusted contacts" notion is not as attractive for an intranet use case using drupal commons. A simpler "post to group(s)" or "post publicly" is a useful config for already private intranets.

My question: Does this patch include the events content type? And can content created for "all" have a condition to not send email notifications, as these general posts may create unwelcome email?

Same patch i have applied and Event content Groups(Separate group names with commas) option for specific group is not working.

I want to remove group functionality totally from commons and yet want other functionalities like posts, events, polls etc. Is it good option to use statuses module? The problem is, the statuses tag module gives some error.

I have read this post, but did not understand much as i am not a technico. I want a simple social network with status posting, hashtag and mentions like twitter or fb or any other network.

Seriously, status posting is a simply basic thing, but connecting it with groups is out of my thinking. Can anyone help?

@japerry you said on #6

site builders can already allow users to post site-wide by tweaking permissions and the view.

Can you please share what are the settings to archieve this please ? I'm on commons 3.14
I've been trying for days without any success.

Thanks

I am using commons-7.x-3.44. Deleted Group Audience field in Group settings. I unchecked "Group content" in content type > edit, but still not able to post "Please enter one more groups where this content will be posted."

There are no group fields in my content type manage field area. Should I delete group fields from the view ui as well?