2

Context

  • D7
  • Views (latest version as of this writing 2017-02)

Scenario

  • SingerRegarn has a D7 view with five displays, where the access control on each display is set to:
    • Access:Permission | View published content
  • SingerRegarn creates another display, but she wants access control to be set to:
    • Access:Permission | Administer users
  • SingerRegarn configures the permissions for the newly created display, using the setting:
    • For: This page (override)
  • SingerRegarn then saves the newly created display.

Problem

  • After saving the newly created display, the permissions for the newly created display do not differ from the other displays, as desired.

Question

  • Is there a bug-fix or workaround to prevent this unexpected behavior?

See also

Improve this question

2 Answers 2

Reset to default
1

Okay, so I put this to the test, using you example. I did not experience any unexpected results. I created 3 displays and set 2 of the displays to Access:Permission | View published content. For the 3rd display, I set it to Access:Role | administrator. When I'm logged in as an Administrator, I can view all three display pages. However, when I try to view the 3rd display page as an unauthenticated user, it returns an access denied error. Displays 1-2 remain visible to an unauthenticated user.

My configuration of display 1-2:

enter image description here

What my view page looks like for display 1-2 (viewed as unauthenticated user):

enter image description here

My configuration of display 3:

enter image description here

View page for display 3 (viewed as unauthenticated user):

enter image description here

I'd double check your configuration to make sure it's correct! If you're still having issues, you could output your displays as blocks. Then you could apply permissions on those blocks using the admin/structure/block interface. You can also plug in view blocks into something like a Panel page, and apply permissions to your Panel pages.

Improve this answer
3
  • Thanks for the reply. The original question omitted a step that allows one to reliably reproduce the problem. The post has been updated to reflect this.
    – dreftymac
    Commented Feb 3, 2017 at 12:15
  • @dreftymac I'd be happy to go back and test if you point out what step I missed.
    – Kellen
    Commented Feb 3, 2017 at 12:21
  • Thanks, it is the second step under the Scenario section of the post. Use Access:Permission | Administer users instead of Access:Role | administrator
    – dreftymac
    Commented Feb 3, 2017 at 12:25
1

Overview

  • Thanks to feedback from Kellen Lester, and a review of some of my old notes, the steps and workaround are more clearly enumerated. There may or may not be a fix for this, but here is a workaround.

Workaround

  • Activate the Master display for the view.
  • On the Master display, set the access control to:
    • Access:None
  • Now, whenever a new display is created it will default to Access: None
  • Now, for every display where a custom permission is desired, the following should produce the expected results:
    • Click None to change the access control
    • Choose For: This page (override)
    • Choose either permissions-based or role-based access control as desired
    • Save the display
  • Result: the custom per-display permissions settings should remain as expected, without modifying the permissions for any of the other displays
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.