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.
Comment | File | Size | Author |
---|---|---|---|
#25 | Screenshot_4_18_13_8_12_PM.png | 66.36 KB | amitaibu |
#24 | og-er-patch.zip | 221.73 KB | jastraat |
#19 | reference-settings.jpg | 105.08 KB | jastraat |
#12 | og_create_ref-1953708-12.patch | 1.01 KB | Hydra |
#6 | 1953708-og-create-er-6.patch | 875 bytes | amitaibu |
Comments
Comment #1
amitaibuCan you attach a db for this scenario?
Comment #2
jastraat CreditAttribution: jastraat commentedAll the user's passwords match their usernames in this simple example DB.
Comment #3
amitaibuI 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 byOgSelectionHandler::getGidsForCreate()
.I can only blame the Entity-reference prepopulate author. Unfortunately, that's me ;)
Comment #4
amitaibuPlease test this patch along with #1958800: AJAX causes entityreference_prepopulate_get_values_from_url to fail
Comment #5
jastraat CreditAttribution: jastraat commentedI 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.
Comment #6
amitaibuComment #7
amitaibuCommitted. Make sure you get the latest dev of ER-prepopulate to check it.
Comment #8
amitaibuComment #9
jastraat CreditAttribution: jastraat commentedI'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.
Comment #10
amitaibu@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?
Comment #11
amitaibuOh, I see the problem. *sigh*, ok, I'll be working on it.
Comment #12
Hydra CreditAttribution: Hydra commentedSo 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.
Comment #13
amitaibuPlease test http://drupal.org/node/1958800#comment-7308434
Comment #14
amitaibujastraat, can you confirm the fix ? I'd like to roll a new version soon
Comment #15
jastraat CreditAttribution: jastraat commentedI 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.
Comment #16
doors CreditAttribution: doors commentedI 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.
Comment #17
amitaibu@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.
Comment #18
amitaibuComment #19
jastraat CreditAttribution: jastraat commented@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".
Comment #20
amitaibu> 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)?
Comment #21
jastraat CreditAttribution: jastraat commentedUser 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
Comment #22
doors CreditAttribution: doors commentedWell @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.
Comment #23
amitaibu@jastraat, are you able to provide a db dump, because I can't reproduce
Comment #24
jastraat CreditAttribution: jastraat commented@Amitaibu - db dump attached. (usernames = passwords)
Comment #25
amitaibu@jastraat, with your db it works fine for me
Are you sure you have the most up to date versions of OG and ER-prepopulate?
Comment #26
jastraat CreditAttribution: jastraat commentedI pulled the latest code from git before testing. My version does also include the patch from #12 in this issue though.
Comment #27
amitaibu> 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 ;)
Comment #28
Hydra CreditAttribution: Hydra commentedWell, 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.
Comment #29
amitaibu@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.
Comment #30.0
(not verified) CreditAttribution: commentedcorrection
Comment #31
drupal3013 CreditAttribution: drupal3013 commentedIn drupal 6 I have the same problem can some one help me please
Comment #32
vistree CreditAttribution: vistree commentedHi,
I had the same problem after setting a group_ref field by hook_form_alter (to allow non-members to add content to a specific group).
Patch from #12 helped.
For OG version = "7.x-2.8"
I only changed the last line to