Group content URL prepopulation has no effect on full form

@RobKoberg, I'm not sure that I follow how what you're proposing would fix the problem. Can you file a patch with your proposed changes?

I'm able to reproduce this with some groups but not others. With the default content installed with Commons, I can reproduce on the Engineering group, but not the Boston group.

Some initial triage:

In commons_groups_entityreference_default_value(), the value is correctly set from the URL as far as $ids around line 584ish, but group IDs are not passed onto the $items array because the og_user_access($target_type, $target_id, "create $entity->type content") conditional is coming back false.

In commons_groups_og_user_access_alter(), we check if the user is a member of the group specified for prepopulation: if (og_is_member($group_type, $group->nid, 'user', $account)) {.

Note, separately from the present issue, I believe this should actually specify the active membership type, rather than any membership type.

In my environment, I'm testing with the default content user "Lisa Rex" whose uid is 6. Lisa only gets successful URL prepopulation with group 1. Not surprisingly, that's the only group of which she is a member:

select * from og_membership where entity_type = 'user' and etid = 6 and group_type = 'node';
+----+----------------------------+------+-------------+-----+------------+-------+------------+--------------+----------+
| id | type | etid | entity_type | gid | group_type | state | created | field_name | language |
+----+----------------------------+------+-------------+-----+------------+-------+------------+--------------+----------+
| 12 | og_membership_type_default | 6 | user | 1 | node | 1 | 1374700268 | og_user_node | en |
+----+----------------------------+------+-------------+-----+------------+-------+------------+--------------+----------+

The group permissions appear to be the same for all groups on the site: non-members don't have "Create Post content" in the UI, though it appears in commons_groups_og_user_access_alter(), we do dynamically assign users the "create $type content" permission when field_og_subscribe_settings is set to "anyone". It seems like this should be reflected in the group permissions UI and the relevant checkboxes disabled if we're going to override their values from what users set.

In commons_groups_og_permission_alter(), we override the names of the "subscribe" and "subscribe without approval" permission to use the word "contribute" instead of subscribe.

I was expecting to see "contribute without approval" granted to all roles for groups where field_og_subscribe_settings is set to 'anyone' but that's not the case.

This patch resolves the issue by granting the "subscribe" and "subscribe without approval" permissions via hook_og_user_access_alter() when group visibility is set to "anyone".

This resolves the missing prepopulation and, in my testing, preserves group access restrictions on prepopulation (eg, the site won't prepopulate a group that you don't have access to contribute to). It would be great to get more functional testing on this. Related: We need better test coverage.

Re:

we do dynamically assign users the "create $type content" permission when field_og_subscribe_settings is set to "anyone". It seems like this should be reflected in the group permissions UI and the relevant checkboxes disabled if we're going to override their values from what users set.

, this would be ideal, but is best left for a followup issue, mainly since hook_og_permission_alter() doesn't provide a way to detect the group entity whose permissions we're configuring. We could certainly discover this through the menu system but that adds enough complexity and isn't critical, thus addressing in a followup issue.

due to some odd caching issues that produces unreliable results (wrong group IDs getting referenced during the og_access_alter check

Thanks for the debugging here, japerry!

+++ b/commons_groups.moduleundefined
@@ -577,14 +579,27 @@ function commons_groups_entityreference_default_value($entity_type, $entity, $fi
-      && og_is_group_type($target_type, $target->type)
-      && (og_user_access($target_type, $target_id, "create $entity->type content") || og_user_access($target_type, $target_id, "update any $entity->type content"))) {
+      && (og_user_access($target_type, $target_id, "create $entity->type content")
+        || og_user_access($target_type, $target_id, "update any $entity->type content")

From my perspective, we should either be able to rely on the results of og_user_access() in all cases or not at all. If we think that function is overly restrictive due to caching, then it seems possible that the opposite is true and that the same caching may allow for privilege escalation. Changing the criteria we use to check for access in one place doesn't seem viable here because we'd have to do similar changes before every call to og_user_access().

+++ b/commons_groups.moduleundefined
@@ -577,14 +579,27 @@ function commons_groups_entityreference_default_value($entity_type, $entity, $fi
+  if(!entity_load($target_type, $ids))
+    return $items;

Coding standards for conditionals (brackets, spacing).

Attached is a re-roll of #9 that also removes our $cache = &drupal_static(__FUNCTION__, array());. This is an artifact of #2019137: Saving a group as "Anyone can join" is saved as "Joining requires admin approval" and I believe it's no longer necessary. In my testing I'm not observing issues that japerry identified in #10 with prepopulate or related values being cached, but it would be great to get some validation of that (as well as general og_user_access() restriction smoke testing).

I think this might have been part of the problem with Cannot create public content in a moderated group

Agreed. Both issues are related to the user and node access systems, which appear to be malfunctioning in your Commons implementation in ways that can't be reproduced in a stock Commons install. #2057961: Cannot create public content in a moderated group has been marked has "cannot reproduce" so "needs review" still seems like the appropriate status here.

#13 is committed. http://drupalcode.org/project/commons_groups.git/commit/05c4f2b.

Documenting that this led to the regression: #2060633: Access denied following "Join" group link.