Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Where is the field_og_access_default_value being removed from the display of the group form? I have a:
function mash_student_group_form_group_node_form_alter(&$form, &$form_state, $form_id) {
dpm($form, '$form');
}
The output of the dpm() says #access is TRUE.
In commons_groups_field_access, and debugging the return value for field_og_access_default_value, the return value is TRUE. How do I get the field to show?
| Comment | File | Size | Author |
|---|---|---|---|
| #52 | user_sign_up.png | 48.74 KB | devin carlson |
| #52 | user_edit_profile.png | 38.29 KB | devin carlson |
| #42 | feature-page.png | 188.86 KB | RobKoberg |
| #42 | Screen Shot 2013-07-22 at 4.01.12 PM.png | 170.36 KB | RobKoberg |
| #42 | Screen Shot 2013-07-22 at 4.01.39 PM.png | 164.84 KB | RobKoberg |
Comments
Comment #1
RobKoberg commentedAnd saving a group produces a fatal error:
EntityMetadataWrapperException: Unknown data property group_access. in EntityStructureWrapper->getPropertyInfo() (line 339 of .../profiles/commons/modules/contrib/entity/includes/entity.wrapper.inc).This group content type was created before (but is the commons group content type) the arrival of field_og_subscribe_settings and field_og_access_default_value.
Next I tried to revert commons group feature. I was able to revert the Field Bases, which gave me the ability to save the node. But, field_og_access_default_value is still not displaying.
I also tried to revert the Field Instances (even though they are identical to a clean install of commons: node-group-field_group_logo node-group-body node-group-group_group og_membership-og_membership_type_default-og_membership_request), but it won't revert. Any ideas how to get that to revert, or perhaps it doesn't matter? However is there something in this non-revert of Field Instances that is causing the field_og_access_default_value to not display?
Comment #2
ezra-g commentedSee #2018039: Group Content Access field is not displayed and thus cannot be used for an explanation of why this field isn't visible and also note #2012730: Document new privacy & trusted contacts fields added in Commons 3.3 for developers .
Thanks for this bug report.
Tagging for the 3.3 radar so we can attempt to reproduce.
Comment #3
ezra-g commentedComment #4
behoppe333 commentedI think I am seeing same bug as #1. After I enable OG Access Control I can no longer save a group. I get error "EntityMetadataWrapperException: Unknown data property group_access"
Here are steps I followed:
When OG Access Control is not enabled, it seems that I can save a group.
Comment #5
ezra-g commented@behoppe333, can you describe step 5? You said you tried to save a group but didn't specify what happens when you do that, so you haven't described the problem :). Thanks!
Comment #6
ezra-g commentedActually, I just re-read #4 and I understand - The problem is *before* step 1. Understood - Thanks.
Comment #7
RobKoberg commented@ezra-g - after install is complete OG Access Control is not enabled. If you create and edit a group then it will work. After enabling OG Access Control, you cannot create or edit groups as a regular authenticated user.
Comment #8
behoppe333 commentedJust in case this helps...
Comment #9
ezra-g commentedComment #10
RobKoberg commentedThis is still an issue as of 40 minutes ago. After doing a fresh install, I left OG Access control off and create a test group. I turned it on and tried to edit the group. I get the EntityMetadataWrapperException: Unknown data property group_access
Comment #11
japerryRenaming this to be more clear, and marking critical as it blocks other issues regarding private groups and testing email delivery. It appears that og_access causes an error with our group creation submit form.
Steps to reproduce:
*Enable og_access
*Create group
Should error on a new install or in any other instance with the error:
EntityMetadataWrapperException: Unknown data property group_access. in EntityStructureWrapper->getPropertyInfo() (line 339 of /mnt/www/html/commonsintdev/docroot/profiles/commons/modules/contrib/entity/includes/entity.wrapper.inc).Comment #12
japerryComment #13
ezra-g commentedI'm not able to reproduce, even with the steps in #11.
So that we can continue troubleshooting, please describe how to reproduce with a fresh install of Commons packaged with build-commons-dev.make.
Comment #14
behoppe333 commentedI am unable to create a group with content hidden from non-members -- so I hope this helps you reproduce the bug I keep hitting.
Here's what I just did--with some site-install and drush specifics just in case I am getting that part wrong
"
Comment #15
ezra-g commentedI believe this is your problem. Per the Commons dev snapshot release notes:
Comment #16
behoppe333 commentedHere's where I need help. If I don't do steps #1 and #2 per my post, then I don't know where is the build-commons-dev.make that I use in step #3 of my post -- where I say "drush make profiles/commons/build-commons-dev.make". Where is the makefile I should use?
PS: When I enter "drush make build-commons-dev.make" in my site's root folder, I get error:
file_get_contents(build_commons_dev.make): failed to open stream: No such file or directory make.utilities.inc:456
Invalid or empty make file: build-commons-dev.make
Comment #17
behoppe333 commentedThanks to help from ezra-g and devincarlson I improved my "create fresh dev install" ability. I still observe the same bug in the end. I cannot create a group with contributed content hidden from non-members.
Here are my new and improved steps to reproduce:
Comment #18
ezra-g commentedMarking as active per the reproduction steps in #17.
Comment #19
devin carlson commentedI'm able to reproduce this by following the steps in #17.
The issue is caused by the group_access field not being added to the Groups content type when og_access is enabled. Manually reverting the commons_groups feature after installing og_access fixes the issue.
commons_groups implements
hook_modules_enabled()to revert its own field_base and field_instance whenever og_access is enabled and, through my testing, these reverts are triggered and run without issue (confirmed by watchdog entries) but both field_base and field_instance do not change and are marked as overridden.I'm continuing to look into this but any suggestions are welcome. :)
Comment #20
behoppe333 commentedThanks, Devin. I confirm your workaround does the trick for me: I disabled commons-groups and re-enabled, and now I am able to save a group with contributed content hidden from non-members. This makes me very happy :-)
It appears that this access control works on new content as it is created, and does not affect pre-existing content in the group. I think a group administrator would expect all content in their group -- past and future -- to obey their most recent edit to their group's access settings. Should I add that as a feature request or is that subsumed in this issue?
Comment #21
RobKoberg commentedAnother way to get create and edit working is to go to admin/config/group/fields and add the group visibility field to the group bundle.
Comment #22
ezra-g commentedI was able to resolve this issue on a reasonably fresh install of Commons by calling module_list() with the $refresh parameter set to TRUE before reverting the Commons Groups field* components in commons_groups_modules_enabled().
It's a fairly agressive solution but worth reviewing.
Comment #23
devin carlson commentedI tested #22 on a couple of fresh Commons installations and found that the commons_groups feature was still missing the group_access field instance after installing og_access.
@ezra-g, let me know if you're experiencing different results with new Commons installations.
Comment #24
ezra-g commentedAn alternative to defining these field instances dynamically would be to always define them, but form_alter them out [edit] *when og_access.module is disabled*.
Comment #25
japerryCannot reproduce via the steps in #17 on a fresh build. Here is a report of the module versions I have:
Run drush pm-update and compare with what you have. I think this has been fixed already.
Comment #26
ezra-g commentedSince 4 people were able to reproduce the problem with relatively recent builds/installs of Commons and we haven't identified a specific change that would have fixed this issue, I'd like to take another look at reproducing again before we mark this as fixed.
Comment #27
behoppe333 commented@ezra-g: I agree with you, and FWIW I have observed for a couple weeks that this bug has "gone away". I am glad I am not the only person who doesn't understand what change caused it to go away.
I recall the bug stopped occurring for me around the time ezra-g posted patch in #22. I never applied that patch however. I just re-build from scratch every week or so.
My ability to help with testing will increase if anyone can give me advice on my setup per https://drupal.org/node/2039063 :-D
Comment #28
ezra-g commentedI was able to reproduce this from a fresh build made a few minutes ago. I recorded a screencast which is now exporting.
@japerry, can you share the process you used to package Commons in #25?
Comment #29
RobKoberg commentedfwiw, in my running project (not a fresh commons-dev install), I had og_access enabled and had no problem creating groups. I copied over profile/commons, cleared cache, ran drush updb (nothing needed updates), and cleared cache again. My commons_groups said it was overridden, but trying to revert does nothing. (still says overriden)
Comment #30
ezra-g commentedHere's the video from #28: http://www.youtube.com/watch?v=wod8YZh4pXE. I plan to unpublish it after this issue is fixed.
It seems clear that the field instances are not defined in some cases, such as a fresh install that then enables OG_Access.modue. I think the proposal in #24 is the most reliable path forward, though I'd still like to understand the discrepancy in japerry's testing/setup process from #25.
Comment #31
ezra-g commentedHere's a patch similar to the approach proposed in #24: Defining the OG_Access fields in all cases.
This needs additional functional testing in these areas, with and without OG_Access enabled:
- Display of the fields
- Entry of the fields
- Behavior of the fields (eg, ability to properly restrict node access
Note that this is only really intended for testing on a fresh installation, though applying the patch and reverting the Commons Groups feature may also resolve the issue.
Comment #32
RobKoberg commentedI just did a fresh install with the patch applied and all was good! (I did this as admin user)
I am pretty sure your patch did not cover creating the group with "Anyone can join and contribute". In case it did, that is still not working.
Comment #33
japerryWorks for me as well on a new install! We may need to revisit how we approach these dynamic fields, but I think for 3.3 this isn't bad.
Comment #34
japerryAlso I re-verified that using Drush avoids this issue, as opposed to using the Modules UI. I can only replicate when I use the modules UI from the browser (in both a fresh install or if I use my build_distro.sh script)
Comment #35
japerryMeant to set it to 'needs' work per conversation with Ezra about some errors with fields showing up (but I can't remember exactly the error)
I'm only seeing Q/A showing up as overridden currently, everything else is set default.
Comment #36
ezra-g commentedIn general it's helpful rather than saying that something is "not working" if you can specify the behavior you observe and how that differs from your expected behavior. In this case, I infer that you are referring to the behavior that would be fixed by #2019137: Saving a group as "Anyone can join" is saved as "Joining requires admin approval".
Re japerry's comment in #35, the unexpected appearance of a field only happened when the patch was reverted, so I think we can disregard that.
I think this is mostly RTBC, but hold off committing on one final verification: @japerry: Did you test node access control restrictions with OG access enabled? Thanks!
Comment #37
devin carlson commentedI haven't come across any issues while testing #31 on a fresh install. With the patch, group posting works correctly and the group privacy settings (OG Access) control group membership and group content access properly (tested using multiple users and attempting to join various groups and view/edit different public/private group content).
Comment #38
RobKoberg commentedOn a relatively fresh install with the patch applied, I get a fatal error when trying to save a group with "Anyone can join and contribute":
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '12-0-all' for key 'PRIMARY': INSERT INTO {node_access} (nid, realm, gid, grant_view, grant_update, grant_delete) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5); Array ( [:db_insert_placeholder_0] => 12 [:db_insert_placeholder_1] => all [:db_insert_placeholder_2] => 0 [:db_insert_placeholder_3] => 1 [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => 0 ) in node_access_write_grants() (line 3551 of /Users/rkoberg/Sites/project-mash/docroot/modules/node/node.module).I have attached a screen grab of my node access table. I don't see how 12-0-all would conflict for a primary key.
When I save a group node with "Joining requires admin approval" (with the hide content either checked or unchecked) I get a javascript alert that says "You are not authorized to access this page." I have already changed the group content type to publish on save (no group moderation).
I will test on fresh install when the dev make file will build commons (og checksums issue).
Comment #39
ezra-g commented#31 is committed: http://drupalcode.org/project/commons_groups.git/commit/c2e99ef.
@RobKoberg, please let us know if you're able to reproduce those errors on a fresh install.
Comment #40
RobKoberg commentedOn a fresh install I do not get the PDOException. Also on a fresh install I set the group content type to publish on create. Both worked fine, but give the notice below.
I copied over the latest commons profile to my (heavily customized) project, cleared cache, ran updates, drush cc all again, and I still get the PDOException. I deleted all content, tried to add a group and get the PDOException.(this sucks)
Fresh install Notice:
Notice: Trying to get property of non-object in commons_groups_preprocess_node() (line 815 of /Users/rkoberg/Sites/commons-7.x-3.x-dev/profiles/commons/modules/contrib/commons_groups/commons_groups.module).Comment #41
ezra-g commentedSorry to hear that you're frustrated here.
Can you confirm whether you reverted all features to their default state?
If so, can you elaborate on the nature of your customizations?
Comment #42
RobKoberg commentedI did (drush features-revert-all):
That went through and reverted the above features, theoretically. Using the web ui, the following still say they are overridden:
* Commons Activity Streams
* Commons Groups
* Commons Like
* Commons Social Sharing
* Commons Trusted Contacts
* Commons Events
I am attaching screen grabs of the features UI, if that in any way can help.
feature-page.png shows the commons_groups feature after reverting the Field instances in the UI (again, after the drush fra). It says the feature has been reverted (success message), but still shows the Field instances needs to be reverted.
Looking at the Review Overrides page show a LONG list of additions. I don't know if it will be helpful to see those, but I am attaching multiple screen grabs that together make up the page.
Comment #44
behoppe333 commentedI just made an instance from scratch a couple minutes ago using drush make build-commons.make. I allowed example content to be created during the install.
I enabled OG Access. Then the site asked me to rebuild permissions. That failed with the error
"An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: /mysite/batch?render=overlay&id=8&op=do StatusText: Service unavailable (with message) ResponseText: OgException: Cannot set visibility of node ID 3 as the group node of type "user" does not have the "Group visibility" field attached to it. in _og_access_verify_access_field_existence() (line 250 of mysite/profiles/commons/modules/contrib/og/og_access/og_access.module)."
I am not sure if I should make a new issue for this
Comment #45
behoppe333 commentedFYI: The error message above (#44) only occurs if I allow install to create example content. If I decline the example content, then after install completes I can enable OG Access and rebuild permissions without a hitch. (And create a new group etc.)
Comment #46
ezra-g commentedDoes this problem happen with 7.x-3.3 rc1? If so, can you share steps to reproduce?
Comment #47
behoppe333 commentedI cannot reproduce with package from August 7. I can only reproduce with "drush make build-commons.make" from August 9 (this morning)
Steps are
BTW the tgz and zip files from Aug 7 are offline right now. I am using copies i saved from Aug 7
Comment #48
behoppe333 commentedBug exists in 7.x-3.3-rc2+0-dev and can be reproduced using steps of #47
Comment #49
ezra-g commentedI'm able to reproduce. The specific error I'm seeing is:
Comment #50
ezra-g commentedComment #51
ezra-g commentedThere were 2 underlying issues here:
1) I identified and filed a patch to OG for #2063385: _og_access_verify_access_field_existence() assumes node group type, throws an exception rebuilding node access.
2) Commons Trusted Contacts didn't define a group_access field for user groups, which contributed to the exception here. This field is now defined. Note that to test the fix here you'll either have to either do a fresh build or:
- Patch OG per #1 in this comment.
- Revert the trusted contacts feature.
- Save all user accounts on the site (or run the trusted contacts batch user update process again).
I've gone ahead and committed the above since the problem seems clearly defined and I'm fairly confident in the fix, and we'd like to get this into the next nightly development build of Commons to help make it easier for folks to test the upgrade path.
Thanks, @behoppe333 for the updated bug report!
http://drupalcode.org/project/commons_trusted_contacts.git/commit/9eea2ca
http://drupalcode.org/project/commons.git/commit/67242a0
Comment #52
devin carlson commentedI'm now seeing a required "Group visibility" field when creating new users or editing existing user accounts.
Comment #53
ezra-g commentedI'm actually not able to reproduce this on a fresh install. Perhaps it only applies to upgrading sites.
Comment #54
japerryI also see neither of these issues on a fresh install or an upgrade.
Please refer to #2065381: EntityMetadataWrapperException errors due to features not being reverted for reasons why its important to revert all features after enabling a feature in commons. We don't automatically revert all features because we don't want to destroy user customizations.
If after reverting all features you still get this error, please report back.
Comment #55
ezra-g commentedI'm also unable to reproduce #52. Marking as fixed
Comment #56
behoppe333 commentedSteps to reproduce bug reported in #52
Comment #57
ezra-g commentedThanks for the report - I was able to reproduce and filed a new issue at #2069119: "Group visibility" field visible when admin adds users through the UI, since the visibility of this field is unrelated to the title and original purpose of the present issue.