Scenario:
Event is a content type.
No users have the create event permission granted by Drupal core roles.
User A is a member of Group 1 with permission to create events in that group granted by OG permissions.
Entity reference prepopulate is enabled on the OG group reference field for event and the group reference field is required.
User A is NOT a member of Group 2, and non-members do not have the create event permission.

If the user goes to:
mysite.com/node/add/event?og_group_ref=1
the group reference field is hidden and prepopulated with the group as expected

If the user goes to:
mysite.com/node/add/event
They get a form error saying that the reference field should be populated via the URL, but only the groups where they have the create event permission appear in the select field => also as expected

If the user goes to:
mysite.com/node/add/event?og_group_ref=2
Group 1 is prepopulated in the entity reference field. (weird)
Group 2 is the OG context from entity reference prepopulate
When the node is saved, the OG entity reference field is empty even though it was a required field. The new node has no group membership and thus cannot be edited by the user who created it.

Files: 
CommentFileSizeAuthor
#25 Screenshot_4_18_13_8_12_PM.png66.36 KBAmitaibu
#24 og-er-patch.zip221.73 KBjastraat
#19 reference-settings.jpg105.08 KBjastraat
#12 og_create_ref-1953708-12.patch1.01 KBHydra
#6 1953708-og-create-er-6.patch875 bytesAmitaibu
PASSED: [[SimpleTest]]: [MySQL] 790 pass(es).
[ View ]
#5 og_create_select-1953708.patch770 bytesjastraat
PASSED: [[SimpleTest]]: [MySQL] 790 pass(es).
[ View ]
#4 1953708-og-create-er-4.patch753 bytesAmitaibu
PASSED: [[SimpleTest]]: [MySQL] 790 pass(es).
[ View ]
#2 og_example.zip260.38 KBjastraat

Comments

If the user goes to:
mysite.com/node/add/event?og_group_ref=2
Group 1 is prepopulated in the entity reference field. (weird)
Group 2 is the OG context from entity reference prepopulate
When the node is saved, the OG entity reference field is empty even though it was a required field. The new node has no group membership and thus cannot be edited by the user who created it.

Can you attach a db for this scenario?

StatusFileSize
new260.38 KB

All the user's passwords match their usernames in this simple example DB.

I see the problem.
You are not allowed to create groups in ?og_group_ref=2, only in ?og_group_ref=1, but entityreference-prepopulate doesn't validate properly as it was asked not to validate by OgSelectionHandler::getGidsForCreate().

I can only blame the Entity-reference prepopulate author. Unfortunately, that's me ;)

Assigned:Unassigned» Amitaibu
Status:Active» Needs review
StatusFileSize
new753 bytes
PASSED: [[SimpleTest]]: [MySQL] 790 pass(es).
[ View ]

StatusFileSize
new770 bytes
PASSED: [[SimpleTest]]: [MySQL] 790 pass(es).
[ View ]

I updated this patch and the related one to include $instance as a parameter, and the two patches fix the issue when I tested. When a group that a user is not allowed to create content in is added to the url, entityprepopulate now ignores the value in the url, uses the fallback behavior, and provides a select field with only the eligible groups.

StatusFileSize
new875 bytes
PASSED: [[SimpleTest]]: [MySQL] 790 pass(es).
[ View ]

Committed. Make sure you get the latest dev of ER-prepopulate to check it.

Status:Needs review» Fixed

Status:Fixed» Needs work

I'm afraid I just tested this patch along with the latest version of ER-populate, and unless I misunderstand the desired functionality, these did not fix the bug.

With these patches, if a user is a member with create permissions in Group 1 and is not a member of Group 2 (and has no create permissions in Group 2), they can still create content for Group 2 if the group ID is passed through the URL. This seems like very undesirable behavior.

@jastraat ,

I have re-checked and it's working fine for me. Can you make sure you have the latest -dev version of both modules and re-try?

Oh, I see the problem. *sigh*, ok, I'll be working on it.

StatusFileSize
new1.01 KB

So basically, we first need to check, if the user is a member of the referenced group and additionally, if he has the permission needed to create the content. Something like this might work.

jastraat, can you confirm the fix ? I'd like to roll a new version soon

I just tested this newest patch with the latest dev of entityreference_prepopulate, and the bug appears to be fixed. Now, if a user doesn't have create permission in a group, if that group ID is passed through the URL, they get an access denied error. (Fantastic!)

However - the fallback behavior if there is no value passed through the URL no longer works. If a user with create permissions (even create permission assigned outside of a group context in the main Drupal permissions) attempts to create content without passing a group ID through the URL, they also get an access denied error. Previously, the fallback behavior (showing a form error and allowing them to select the group) was applied.

For my purposes, this is preferable, but it may not be for everyone.

I am using Drupal Commons 3.2 (Just upgraded from 3.1) with Domain Access and this change has not worked for me.

The user can still add a group id that he/she is not a member of a add content to it.

@jastraat, thanks! Indeed I've missed the "hide" fallback behavior. I've opened an issue for that -- can you confirm it's working for you? #1973026: Fix 'hide' callback for OG fields

@doors, you will have to apply a patch, or wait for a new release which should be in a couple of days.

Status:Needs work» Fixed

StatusFileSize
new105.08 KB

@Amitaibu, unfortunately I don't think the patch from http://drupal.org/node/1973026 fixes the issue with fallbacks that I mentioned. I applied the patch, but I still get an access denied error on create if the URL doesn't contain a Group ID parameter.

I've attached a screenshot of my field settings. The entityreference field is required and I am using "Strict node access permissions".

> but I still get an access denied error on create if the URL doesn't contain a Group ID parameter.

Sorry for the stupid question, but are you sure you pass a correct group ID (if not, maybe that user doesn't have groups they can post to)?

User is a member with create permission in Group 1 and is not a member of Group 2.
node/add/post?og_group_ref=1
- works and the entityreference field is hidden.

node/add/post
- access denied

node/add/post?og_group_ref=2
- access denied

Well @Amitaibu I applied the patch in #12 and also the patch at http://drupal.org/node/1973026 and it seems to work by giving an Access Denied page even though when Fallback is set ti redirect.

The thing is though that if the action is set to "nothing" the Group that the user does not have access to is still shown in the drop down list and if selected the content is still added to that group the user does not have permission to.

Status:Fixed» Active

@jastraat, are you able to provide a db dump, because I can't reproduce

StatusFileSize
new221.73 KB

@Amitaibu - db dump attached. (usernames = passwords)

StatusFileSize
new66.36 KB

@jastraat, with your db it works fine for me

Screenshot_4_18_13_8_12_PM.png

Are you sure you have the most up to date versions of OG and ER-prepopulate?

I pulled the latest code from git before testing. My version does also include the patch from #12 in this issue though.

> My version does also include the patch from #12 in this issue though.

Nope, it shouldn't. (btw, Sorry @Hydra, forgot to say thank you -- but the patch isn't right ;)

Well, for me it worke'd, but if there is a better solution, I'm very happy with it :) I love your work, so I have to thank you!
Okay at least there is no group selected if the user has no access to. But the user has access to the node create/edit formular (of course he has to select a group), but I need the user to get a 404 if the og_group_ref is an ID where the user has no access to (eather if he is not a group member or has not the permission in the group). Any Idea how to achive that?

I belive the original issue is fixed. You cannot create content in other groups anymore.

Status:Active» Fixed

@Hydra ,

> I love your work, so I have to thank you!

Thanks :)

> but I need the user to get a 404 if the og_group_ref is an ID where the user has no access

That's custom - you can implement hook_node_access() with your own logic.

So, marking issue as fixed, thanks all.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue summary:View changes

correction

Issue summary:View changes

In drupal 6 I have the same problem can some one help me please