drealty_drealty_listing_access() checks access for "$op any $type_name drealty_listing" and "$op own $type_name drealty_listing"
However, for create and view, these are the wrong permission strings.
The relevant strings are "create $type_name" and "view $type_name", which are never checked.
Therefore access is never granted for this check.
This is mostly relevant since entity_access() calls this function (indirectly via drealty_listing_access()), and never invokes drealty_access().
Therefore entity-based features, like entityreference_prepopulate, fail for non-admins.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | drealty-access_access_access-2120455.patch | 800 bytes | aaronbauman |
Comments
Comment #1
aaronbaumanIn fact none of the permissions checked in this function exist.
I'm not sure if I understand the motivation behind this function clearly -- looks like it was designed around a permissions structure that was never built, or was removed.
If there's a reason against using a simple pass-through to drealty_access, i can't see it.
Comment #2
alexweber commentedLooks fine to me but I'm gonna wait for Kevin to take a look before committing anything on this one...
Comment #3
droddis commentedhas anyone had a chance to review this? I think this is related to an issue I'm having passing images to non authenticated users using the Juicebox module. Authenticated users can see images within the module, but non authenticated cannot.
Comment #4
droddis commentedFor what's it's worth I've tried this patch and it fixed my Juicebox module integration with no apparent ill effects to date. I'll update if/when I run into any issues.
thanks for the timely fix!
Comment #6
shauntyndall commentedI committed based on the community review comments. Patch applied cleanly. Thanks!