Posted by marco.abiuso.questar on December 23, 2011 at 12:09pm
2 followers
| Project: | Views PHP |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
When using a PHP for access condition to displays with the same path, Master display is returned instead of the granted access display.
Steps to reproduce:
- 1. Create a View (e.g. showme on /showme)
- 2. Add a footer Global Text "FooterMaster"
- 3. Override the footer editing it and selecting For "This Page (override)" with text "Footer1"
- 4. Add a Page
- 5. Set the path as the same view (/showme)
- 6. Override the footer of the second page editing it and selecting For "This Page (override)" with text
"Footer2" - 7. Change access in the first page to All displays (except overridden) to PHP, then set "return FALSE"
- 8. Change access in the first page to This page (override) to PHP, then set "return TRUE"
- 9. Open /showme and check that footer is "Footer1"
- 10.Change access in the first page to This page (override) to PHP, then set "return FALSE"
- 11.Change access in the second page to This page (override) to PHP, then set "return TRUE"
- 12 Open /showme and check that footer is FooterMaster (should be Footer2)
At this point Views is ment to show the first display that grants access
http://drupal.org/node/278651#comment-908464
If you use Roles Access instead of PHP, it works as intended (e.g. set All displays to role Admin, then override page 2 and set role Anonymous and it shows "Footer2")
Comments
#1
This issue can be renamed as:
views_php_access only gives access to the first display, otherwise shows default display (if any of the displays has access).
The problem was due to the fact that the checks are done on the wrong display id, i.e. $this->view->current_display instead of $this->display->id ($this is the current view object).
At the view access checking stage, the current_display variable is always 'default', so, even if the checks are run on the correct display, only the default display results accessible (the display id serves only for naming a runtime generated access function containing the custom PHP)
I'm attaching a patch.
P.S. I had to dive into views module internal workings to get the solution: not a funny task, for a so small bug ;-)
#2
perhaps a different issue; but as far as i can tell php access control does not work.
my simple function:
return false;
view is still visible.