It only appears to prepopulate the field when logged in as the super admin. When I switch to another account, it doesn't prepopulate. I've tried this with both the recommended and dev branches.
| Comment | File | Size | Author |
|---|---|---|---|
| #26 | screenshot.JPG | 14.28 KB | mlzr |
Comments
Comment #1
EGamerHDK commentedI second this. It's a HUGE problem. I manually have to change what group a piece of content is available to.
Comment #2
EGamerHDK commentedI'm able to get it to work if you go into the content type and go to edit the group audience entity reference. Change it from "My Groups" to "All Groups"
Comment #3
tevans commentedI'm a little confused. So do you mean the edit screen for the entity reference field? I have a content type "Interaction" with an entity reference field of "Contact", so the URL I am talking about here would be '/admin/structure/types/manage/interaction/fields/field_contact'. Sorry, I'm just not finding anything resembling what you are talking about.
Comment #4
EGamerHDK commentedGo to structure -> Content Types -> Edit the content type -> Manage Fields -> Edit the "og_group_ref" field -> Scroll down to "Reference" -> Change to All Groups.
Comment #5
amitaibuIt works ok with latest -dev + OG 7.x-2.x
Comment #6
tevans commentedWhat if you don't use Organic Groups? Is that now a prerequisite for this module?
Comment #7
amitaibuNo
Comment #8
EGamerHDK commentedYep, seems like the new version of Entity Ref Prepopulate got rid of (Reference -> Change to All Groups)
Works perfectly now. The new dev version of OG breaks my public and private groups though. Just as a note, if anyone is thinking of upgrading.
Comment #9
zatarain21 commentedsubscribing
Comment #10
amitaibu> The new dev version of OG breaks my public and private groups though
For specific issues on OG, please open issues there. And better -- provide a patch :)
Comment #12
whop commentedHello I still have this problem with OG 7.x-2.2+32-dev
using 1.3 Entity ref. prepopulate.
Meaning, everything works fine for admin, but for ather users, field is blanc (or hiden, or disabled if set so).
Could you please help ?
what sould I check for "og_group_ref" field" there is no "all Groups" option.
Thank you
Comment #13
whop commentedplease, was anybodz able to work it out ?
just to say, for normal entity its working, but if I have to prepopulate OG ref ffield, its working only for admin.
thanks
Whop
Comment #14
jraviotta commentedEntity reference Prepopulate is only prepopulating fields for my superuser account. The og_group_ref field shows "none" for all user roles except superuser. I have tried every conceivable permission setting for site-wide user roles as well as in the group context.
Has anybody found a reason for this behavior?
UPDATE
I updated File entity (fieldable files) to 7.x-2.0-alpha and the problem resolved.
https://drupal.org/node/2067673
Hope it works for you.
Comment #15
whop commentedThanks, but not working for me.
could you describe your enviroment...I mean versions of related modules.
I switched some user to administrator group member, then it works, but not for normal members.
Other entity references (ie nodes) works without problem for normal users.
Thanks for help, i am hopeless.
Comment #16
gbirch commentedI was having the same problem with entity references to crm-core contacts. Turned out that the users for which prepopulate was not working did not have permission to view all contacts of the given type. Once I gave them permission, it worked. Presumably the entity reference field itself is not permitting values that the given user does not have access to?
Comment #17
aleck_wi commentedThis is a problem of OG. Entity reference prepopulate working correctly.
I have tested the issues related to the OG behaviour on new and working sites (dev and stable releases).
Step by step guide for get successful prepopulation:
- install OG, OG subgroups, (OG vocab if required)
- create Entity type Group and activate checkboxes Group and Group content
- activate Entity Reference Field properties to Prepopulate in accordance with any internet guides (you can hide or not the field on prepopulation)
- set default value Group and deactivate check box Hide field and use default value for Group field of the content type
- create any required permission to the Group content type on User roles tab and OG Roles in Administration menu. You must add only one permission for good result - Administer Organic groups permissions
- add group and be sure that checkbox Group is checked !!! this is one of general requirements
- look at the id of previously created node and add another group by next url "node/add/GROUPCONTENTTYPE?og_group_ref=IDOFCREATEDENTITY (for multiple parents values you need use ?og_group_ref=IDOFCREATEDENTITY,IDOFCREATEDENTITY,IDOFCREATEDENTITY)
- also look at the Group check box and save
You will obtain required group with prepopulated og_group_ref field.
HOWEVER NOTICE!!
- you will not get multiple parents in prepopulated field without hacking of the module - it loses all values and get only last (I wrote about this in issues. I suppose that some other procedure call owerwrites $ids values). For successful multiple og fields prepopulating you need force the module set $ids variable without IF clause by call function ...GET_IDS_FROM_URL
- however prepopulated values can be lost after saving the node and after that you need to set OG audience again by hand - reason OG group field is unchecked and og_group_ref is cleared after node save. This possible if user can't use Administer Organic groups permissions. When a user that hasn’t above stated permission try create group Drupal doesn't associates him with Admin permission of this group and doesn't provides right to change the field. After saving the node user became the owner and can change audience by hand.
Conclusions:
- if we need that user be able create any groups structures than OG module must prevail the standard permission settings and must limit this permission by own OG group's role permissions Edit and Delete own groups.
- prepopulate module must take all url's parameters and place them correctly into the $ids and do this correctly for all cases Ajax, global variables...
That's all folks :(
Comment #18
adehoedt commentedTried uninstalling OG and had no success resolving this issue.
Reverting to 7.x-1.0 resolved this issue for us.
Comment #19
mattsmith3 commentedHad the same issue and noticed comment #16.
Here's a tip for those using a references view (as a fallback)- if you should need it. On the view settings (under Advanced) there are "Query settings". Check "Disable SQL rewriting" and the view will ignore permissions to render the desired output. Goes without saying... but use this setting at your own risk.
That said, the field still isn't hiding when pre populating. I'll look for that separately.
Comment #20
zulfierken commentedI have a similar problem
1- I gave create content permission with using OG Node permissions to the non-members
2- I prepared links for prepopulate
It works perfect for members and superuser (non-member0
3- But it does not prepopulate for non-member.
Problem is definitely access permission (I think it does not prepopulate if the user is not group member)
Any solution to prepopulate group audience field for non-members?
Comment #21
jlbellidoSubscribe, it doesn't work with OG --dev and erp --dev
Updated: It works with OG --dev and erp --dev only if I don't do a AJAX call like upload a file. If i do a AJAX call like upload a file it only works with Super admin role. Is this an other issue?
Comment #22
ThePeterYu commentedPlease note, I am not using OG and it still doesn't prepopulate unless I login as Admin. Any workaround would be very helpful and much appreciated!
Comment #23
mlzrHi, i had a problem, i can't use "Entity reference prepopulate", and no groups appeared in the "Groups audience " field.
Logged in as admin it works fine!
I find out when the group is NOT bublished, this is exactly what happend. Bublish the group, and things start working.
BUT this is not a fine solution, I don't want the groups to be public! Then everyone can see the group name and the users in it. That's a no- go.
Why can a group member not select a non-published group?
It looks like a views with the filter " Inhoud: Gepubliceerd (Ja) " . Can it turned off, then the problem is gone.
I want the group not published, but a group member can still put content in it.
Ideas?
Comment #24
mlzrGot it. I was thinking not publishing the group then I can hide the group itself for the outside world. This is the normal thing to do with hiding content for the outside world.
Maar met OG is het anders: you can hide a group with a function of OG itself.
The settings:
I had to publish the group, and use "Organic groups access control
(og_access)" , to hide the group for the world.
- enable the module "Organic groups access control"
- go to "OG field settings", and give the 'bundle' witch is the group you want to hide the field "Group visibility".
- then go to the group, and set "Private - accessible only to group members"
- be sure the group itself is published.
Done!
now I have a group, when i acces it not- logged in i get an "access denied". But a group member can select the group, and "Entity reference prepopulate" works too.
Comment #25
mlzradd onn .. When the group is not published, "Entity reference prepopulate" don't work.
with above settings "Entity reference prepopulate" works, and the group is still hidden.
Comment #26
mlzrComment #27
rafaelferreir4 commentedGuys, any update on this? I am not using OG as well and it only works if I am logged in as admin.
Comment #28
rafaelferreir4 commentedComment #29
johnhanley commentedI ran into this problem today. That is, prepopulation of entity reference fields only occur for super admin.
However after some digging, I realized prepopulation is tied to permissions.
For a user reference you must enable
View user profiles
For entity reference you must enable
View [type] [bundle] Entities
This creates a problem because I don't want individual viewing of these entities, especially user profiles, and forces me to use a module like Rabbit Hole to control viewing.
It seems like it would make more sense to change the entity reference permission to something like
View List of [type] [bundle] Entities
Comment #30
wind_kind commentedAny updates on this?
Comment #31
michellezeedru commentedChiming in on and following this issue. Having the same issue trying to reference an order from Ubercart. My Entityreference Prepopulate field only works for users with View All Orders access. Definitely not okay. Will look into Rabbit Hole as a workaround until there is a better way. Thanks!
Comment #32
Yuri commentedAs mentioned in #24, in my case the entity was not published, therefore an entityreference to an unpublished entity cannot be created, thus the field stays empty.
Would be nice if this worked for unpublished content though.
Comment #33
lukedekker commentedExperiencing the same thing with a slight exception. It works perfectly for any user/role that has the permission "Administer Site Configuration" (No idea why). Since this is such a far-reaching permission, this isn't really a viable workaround. It just points towards the root issue.
Comment #34
siramsay commentedas in #32 I had the same problem with not published nodes. the nodes do show in the select menu and can be selected but just can't be referenced from URL. I am using a views entity reference list with Disable SQL rewriting as noted above.
I found that commenting out line 312 unset($ids[$delta]); in entityreference_prepopulate.module
it seem to check if not "view" access and unsets, unsure what the implications of this are, but since the decision above to Disable SQL rewriting and unpublished nodes are in the view I can't see why this access check is needed.
Comment #35
siramsay commentedas stated above. since this is a addon module to entity reference in that it requires entity reference then would it be safe to remove content access check entirely?
Comment #36
nancydruSize, you might want to checkout #2383265: You can't prepopulate a reference to an entity that you don't have view access to. There's a patch there that turns that off.
Comment #37
nancydruComment #38
siramsay commentedThanks NancyDru, I will test the patch as suggested. Seem to do as I suggest by adding a check box to the field edit page to give you the choice whether or not to unset the ids instead of just doing it manually as I have done. In my case since this is the only place I have used Entityreference prepopulate it arrives at the exact same outcome.
My question is still relevant, is access check needed as the check has already been done in entity reference?