counters in Tab-widgets are not correct

Thanks for the report. Adding to the 3.4 radar.

I'm looking into this issue today, however please note the latest Commons dev snapshot is from 2013-Sep-26, rather than mid-August.

the relationship should not be required and all content displayed.

I tested this hypothesis by creating a "post" node outside of any groups.

I made the following changes to the commons_bw_all view, reverting back to the default between each change so that I could test the changes in isolation.

I set the exposed "following" filter to display all content regardless of whether it was flagged in all tests below where the exposed filter was present. The list below is in the format of "Change made: Whether the post node outside of groups appears in the view when the view is previewed":

* View in its current state in the Commons codebase: doesn't show
* Remove only OG membership relationship: Doesn't show
* Remove only flag relationship: Doesn't show
* Make OG relationship not required: doesn't show
* Make OG relationship not required *and* remove "group content type" filter - post shows.

So, it seems like the filter introduced in #2037417: All views using OG references require a OG group type filter is more likely part of the discrepancy. We may also need to change whether the group relationship is required for the other commons_bw views for consistency.

As outlined in the OP here, there are 2 parts to this issue:

1) Whether the site homepage browsing widget should include content posted outside of groups as its default behavior.

2) Tab counts being out of sync with their counters.

@slowflyer, can you provide steps to reproduce the second item? I haven't been able to do so yet.

Thanks for those reproduction steps, slowflyer!

Here's a patch to address the incorrect tab counts as in the 2nd part of the OP. It would be great to get your review here! Please note that you need to clear cache and run update.php or the "drush updatedb" command.

I believe having the site homepage browsing widget include content outside of groups is a new feature request, so I encourage you to file one so that others who are interested can express their interest.

But there is one remaining question:
The user creates a post using the small widget form and does not assign any groups - maybe by accident -
In this case the content is not displayed a little confusing because the look and feel suggests that the content a user enters in the form, will be displayed below after saving - no matter of assigned to groups or not.

That's a good point, slowflyer. I was thinking in the context of the Trusted Contacts feature being enabled, which enforces form validation to ensure that content from the browsing widget has a group audience (either in the og_group_ref field or to a user's trusted contacts. You're right that without this validation, the proposed patch could make some potentially confusing behavior possible.

Agreed on the UX issues. Marking needs work for additional form validation so that at least the current Commons behavior is consistent with/without Trusted Contacts enabled.

Re-roll per #12.

Note that I added a call in commons_bw.module to node_validate(). The documentation at https://api.drupal.org/api/drupal/modules%21node%21node.api.php/function... claims that field_attach_validate() invokes hook_node_validate() but I don't see how that's accurate looking at the codebase. I'm asking folks who might be able to weigh in and update the documentation if it needs revision.

#13 is committed: http://drupalcode.org/project/commons.git/commit/726a400.

Thanks for the helpful feedback, slowflyer! Let's continue with the feature-request aspect of this issue in #2020061: Allow users to create content outside of groups.

I left a draft validation error message in here. "needs more groups" - We should have a more appropriate message.

http://drupalcode.org/project/commons.git/commitdiff/1e6b7c7?hp=3259dbf2...

Yes, that's what we fixed with #16, thanks!

I just wanted to point out https://drupal.org/project/entityreference_count does the same thing in a more modular way. Every thing works as expected, but I do have an issue, https://drupal.org/node/2103371.

Once enabled, the counts can be initialized/updated by:
* go into maintenance mode :)
* Use devel's Execute PHP code to run (or create code to run in an update):

$nids = db_query('SELECT nid FROM {node}')->fetchCol();
foreach (node_load_multiple($nids) as $node) {
  node_save($node);
}