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

Sorry to hear that you're having problems here. Adding to our Commons 7.x-.3.6 radar for triage.

Hello, this issue is due to the trusted contacts module not being reverted after the documents feature is enabled. Once you revert trusted contacts, this issue should go away!

Marking as postponed pending more info. Please let us know if japerry's suggestion above resolves your issue.

What a fun issue! Not.

So I've done a bit of re-writing here because a few assumptions made back when trusted contacts and commons_groups were made, have changed.

Biggest change is relying on site-wide permissions for group posting, as well as removing groups from being a required field (when trusted contacts were added)

This essentially means that any 'node/add/(content type)' link should allow someone with sufficient privileges to post outside of a group. We let OG and entity reference permissions handle this now. Because of this, we can remove the node_validate function within commons_groups.

Secondly, with trusted contacts added and og_access optional, we had to make a few use cases for the bw_widget, which is where we really want to be controlling if people could accidently be posting outside of groups. For now (because of site-wide views on the front page), we've decided that the bw_widget should not allow site-wide posting of group content. I've altered the validation functions in this patch to work mainly on the bw_widget to disallow site-wide posting.

I've also fixed the earlier bug where trusted contacts can deny people from being able to post within a group when og_access is disabled.

All said and done, this has been fairly well tested against the above use cases and I think is good to go for 3.6

Thanks, japerry!

We'll do some functional testing on this today. One part of the code that may need revision is this:

-  else if ($group_audience_type == 'custom' && !empty($node->{OG_AUDIENCE_FIELD})) {
+  else if (!empty($node->{OG_AUDIENCE_FIELD}[LANGUAGE_NONE])) {

At a glance, I'm not sure if we can count on LANGUAGE_NONE here in all cases. Also, marking #2160221: Missing validation on frontpage short form as duplicate of this.

Based on my functional testing on a single language site, #7 seems like a solid stopgap. I think we can use this approach and then pursue a more comprehensive fix as part of #2020061: Allow users to create content outside of groups, ideally for Commons 7.x-3.7.

My experience has been the same as #9.

The only issue I've come across is the poor UX of displaying an error message to users but not showing the associated field (as it is hidden by Drupal.behaviors.commonsBwExpandableForm).

I'd suggest doing something like:

      // Hide the hidden fields on load unless they have an error.
      if (!hideables.find('.error')) {
        hideables.addClass('element-invisible');
      }

in order to prevent fields which have an error from being hidden on page load.

An updated version of #10 which addresses an issue where the group form item was never hidden with translation enabled and makes the display of expanded forms which have an error more consistent with standard expanded forms.

An updated patch to change the error message from

Please enter one more groups

to

Please enter one or more groups

This was committed to Commons 7.x-3.x with http://drupalcode.org/project/commons.git/commit/1b26b13

Linking to #2020061: Allow users to create content outside of groups

We're working on a more robust followup fix at #2020061: Allow users to create content outside of groups.