Problem/Motivation

When using multiple displays on one view, changing the access permission on one display can affect other displays.

Steps to reproduce:

1. Create a view
2. Create a page display on the view, which we'll call page A
3. Set the access on this to 'User permission', and pick a permission, say 'View site reports'
4. Create a new page display, which we'll call page B.
5. Set the access on this:
- click the permission name in the UI
- select the 'override' in the dropdown
- select a different permission, say 'Access content'

Go back to page A.

Expected result: page A is unchanged, because on Page B you selected 'override'

Actual result: page B has changed its permissions as well!

Workaround

If you first override the access control type ("Permission" or "Role"), you can then override the corresponding settings for that particular access type.

Original report

This is similar to http://drupal.org/node/1144740, but different. With the latest 5/28/2011 dev build (though I can't be entirely certain this bug is new to this build), I cloned a page display. I then changed Page Settings > Access > Role, with an override for that display. But no matter what I do, whether I remove all overrides for Page Settings, save, and try to redo the override, regardless of which display I try to create the override on, all displays remain linked and no overrides actually work, even though the override is indicated as being in effect.

CommentFileSizeAuthor
#45 views.1174588.45.patch5.02 KBdagmar
FAILED: [[SimpleTest]]: [MySQL] Failed to run tests: tests were executed, but no results were found. View
#45 views.1174588-test-only.45.patch3.15 KBdagmar
FAILED: [[SimpleTest]]: [MySQL] Failed to run tests: tests were executed, but no results were found. View
#22 export.txt267.46 KBjohnv
#14 1174588.patch1.26 KBdawehner
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1174588.patch. Unable to apply patch. See the log in the details link for more information. View
Members fund testing for the Drupal project. Drupal Association Learn more

Comments

David D’s picture

I'm also wondering if this might be related to D7.2 somehow. I also just saw similar flakiness with adding a header to a display, as an override, only to see it appear on the other 2 displays. However, in this instance, when I removed it from the first display, it also vanished from the second display, remaining only on the third display, as I originally intended.

There's a possibly related behavior I've been seeing for weeks at least: when I add a new override to a display, the changes I make with the override will not be saved along with the override status, only the override status itself. I then need to re-edit the setting in question and do my changes again, in order for them to stick. As a result, I have been developing the habit of just changing the override status alone, closing the dialog, and re-opening it to make the actual changes that I need the override for.

dawehner’s picture

I'm pretty sure that once the pager is fixed, this will be fixed, too.

David D’s picture

You did note that what I'm reporting doesn't involve the pager per se, right? I'm no coder, so I can well imagine that the pager is involved in this in some non-obvious way, but I'm just sayin'.

merlinofchaos’s picture

Status: Active » Fixed

This is fixed by the patch here: http://drupal.org/node/1144740#comment-4547898 -- that patch fixed pager as well as access and exposed form which both suffered the same problem.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

jbova’s picture

Version: 7.x-3.x-dev » 7.x-3.0-rc1
Status: Closed (fixed) » Active

This doesn't appear to be fixed with the aforementioned patch. I'm using 7.x-3.0-rc1, which has the code modified as in the patch. However, whenever changing the access permission, and choosing "this page ( override )", it changes all displays. There doesn't seem to be any way to set access permissions per display.

dawehner’s picture

Status: Active » Postponed (maintainer needs more info)

Can you please try to update to views 7.x-3.x and try it again?

jbova’s picture

I updated to 7.x-3.x and the problem persists in some form. I can override the first page display. It becomes italicized in the view to mark it as overridden. However, I have two other displays, a block, and a draggable table. These can not be set independently. Whatever permission I set in one, becomes set in the other.

dawehner’s picture

Version: 7.x-3.0-rc1 » 7.x-3.x-dev

Update status. It would be really great if you could post a step by step explaination what you do, so it get's really easy to reproduce the bug.

jbova’s picture

Okay, I just walked through the following steps to create and test on a new view. I was able to reproduce the problem.

First, create a new view.

  • Go to Admin -> Structure -> Views.
  • Click on Add a new view.
  • Create a Title for the view.
  • Check boxes for creation of Page and Block displays.
  • Click Save and Continue.

Add a new Page display to this view.

  • Click on Add -> Page to add a new page display.
  • Give this new display a path, and a name of "Page2"
  • Optionally save the view.

Now that the view is created, we can demonstrate the problem by trying to change the permission on the new page display.

  • Edit the Page2 display.
  • Click on the link "View published content" next to Access.
  • Set the "For:" field to "This page (override)".
  • Change this value to "Administer Content"
  • Click on "Apply (this display)"
  • Result: View the first Page display, and the Block display, they will both have their Access values changed to "Administer Content".

So, let's try to change the access of the Page and Block displays back without changing the Page2 display.

  • Click on Page display
  • Click on the link "Administer Content" next to Access.
  • Set the "For:" field to "This page (override)".
  • Change this value to "View published content"
  • Click on "Apply (this display)"
  • Result: View the Page2 display, and the Block display, they will both have their Access values changed to "View published content".
dawehner’s picture

Priority: Normal » Critical
Status: Postponed (maintainer needs more info) » Active
Issue tags: +D7 stable release blocker

Thanks for this really detailed explaination! It's possible to reproduce this bug.

OH! This is at least major if not critical. Sadly i can't fix the problem at the moment, but this could be the 2AM Malus.

bojanz’s picture

Overriding-issues--.

Will take a look tomorrow.

dawehner’s picture

Issue tags: +override-problem

Just tagging to catch them all.

dawehner’s picture

Status: Active » Needs review
FileSize
1.26 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1174588.patch. Unable to apply patch. See the log in the details link for more information. View

Let's try this one. I'm totally unconvinced that this is the test way to solve it, but at least my tests worked as i expected them.

alberto56’s picture

subscribing

iamEAP’s picture

Title: Override on page access changes all displays » Overriding Access Type Settings Changes All Displays Unless Access Control Type is Also Overridden

I was able to reproduce the bug described, however I was also able to work around the bug by doing the following:

If you first override the access control type ("Permission" or "Role"), you can then override the corresponding settings for that particular access type.

I've edited the title of this issue to reflect what the problem is more specifically.

dawehner’s picture

@iamEAP
Did you tryed to current dev version or RC1? There is a fix for the override-problem in the dev version.

dawehner’s picture

Priority: Critical » Normal
Status: Needs review » Postponed (maintainer needs more info)
Issue tags: -D7 stable release blocker

Update status.

iamEAP’s picture

I experienced that on RC1. Will plug in the dev version later this evening and report back.

johnv’s picture

Title: Overriding Access Type Settings Changes All Displays Unless Access Control Type is Also Overridden » Overriding 'Display access settings' changes all displays unless 'Access control type' is also overridden

I have some more information/symptoms/features, using dev-19-nov-2011 and D7.9:

1. Under 'Settings - Access' (e.g., 'Access: Role | editor') you can either click on 'Role' or on 'editor'. This displays the pop-up-box 'Access restrictions' or 'Access options'. Overriding the display ONLY works when you use the 'Access restrictions' box.
(Compare this with the 'Format settings', which is analog, and where 'page override' DOES work in both cases.)

2. (I will create a separate issue for this if necessary, but i migth be a cause)
"The Access settings for the MASTER display should not be taken into account for other displays. Especially since showing the master display is an advanced option, hidden unter the Views-Settings page."
- Create a View with a master 3 displays;
- display 1 is for general purpose: set&override the 'Access settings' for this page to 'Authenticated user';
- display 2 and 3 are displays for users of 'editor': set (do not override) the 'Access settings to 'Role : editor)
- Save the view.
Now try to view display 1 with an 'Authenticated user' : In Google Chrome, there is no problem, but IE8 will crash!
IMO display 1 uses resources from master, where it shouldn't.

dawehner’s picture

"The Access settings for the MASTER display should not be taken into account for other displays. Especially since showing the master display is an advanced option, hidden unter the Views-Settings page."

That's my biggest critique on hiding the master display. It hides information which the user actually have to know to configure a view.
The user has access to change data of the master via the override-toggle but he actually never sees the master display. In fact technical views itself on the non-ui level doesn't have a clue about the fact that the user doesn't see the master display.
In general the master display/let's called it default from now on, is really the root of all options, so it have to be used.

As i understand you right you have overridden the access setting but still the setting of the master display were used? That's definitive not what it should do.

So some more specific questions

'. This displays the pop-up-box 'Access restrictions' or 'Access options'. Overriding the display ONLY works when you use the 'Access restrictions' box.

It seems to be that you want to override the settings but not the plugin, right? That's technical not possible, so you have to override both at the same time. While using the same plugin is overridden as well.

Does display1,2,3 share the same path?

What does crashing means in IE8? The program is stopped? Nice.

As always it would have been cool if you could have provided an export as this lowers the start-time to look at the issue.

johnv’s picture

FileSize
267.46 KB

ad 1. "It seems to be that you want to override the settings but not the plugin,"
no, that is not what I want, but when clicking around the two fields, the behaviour is sometimes a bit awkward. Never mind, I thought it might have something to do with it.

ad 2. Now try to view display: In Google Chrome, there is no problem, but IE8 will crash! This means:
- "Internet Explorer has stopped working" ; you can only choose [Close program]
- IE8 tries to reconnect twice, then ean error page appears:
-- the URL is "res://ieframe.dll/acr_error.htm#hunkemoeller.nl,https://sid.hunkemoeller.nl/
-- the 'More information' part of the page says: "When a website causes a failure or crash, Internet Explorer attempts to restore the site. It stops after two tries to avoid an endless loop."

As for an export: when I wrote the issue, I had already resolved it. It now appears again, when adding the display Page_teasers, which you'll find in attached export-file.

johnv’s picture

Status: Postponed (maintainer needs more info) » Active
johnv’s picture

I am not sure if this issue is still on focus, but I found the solution for my problem at #20

2. (I will create a separate issue for this if necessary, but i migth be a cause)
"The Access settings for the MASTER display should not be taken into account for other displays. Especially since showing the master display is an advanced option, hidden unter the Views-Settings page."

As promised, here is my issue describing a workaround for the problem #1376470: Gmap Views display with AJAX enabled crashes IE8 (under conditions)

ckng’s picture

Still able to reproduce the bug based on #10 & #16.
Tested on 7.x-3.0-rc3, 7.x-3.0 and 7.x-3.x-dev

jeffersonjhunt’s picture

Version: 7.x-3.x-dev » 7.x-3.1

I can confirm the same issue exists on 3.1. Changing the access in anyway changes it for all displays (page, block, feed, etc... ) on that view.

WebJohn’s picture

True. Note the workaround in the issue title also. Ensure that the access type (eg: role) is also overridden for the display.

dawehner’s picture

I'm somehow wondering why it always works for me. Sorry for being such bad at reproducing issues.

Maybe you all get confused that the override works for the access type and the access setting at the same time.

gerards’s picture

I get exactly the same problem (using access -> roles) , with several attempts, mixing the master display as well.
Drupal 7.9
views-7.x-3.3
My workaround is to define two views :
a) one with (eg) a display page settings -> access -> role -> authenticated user,
b) and the other one with (eg) a display page settings -> access -> role -> anonymous user
Of course this bug weakens considerably the interesrt of displays, but still it is not critical.

Taxoman’s picture

Version: 7.x-3.1 » 7.x-3.x-dev
Priority: Normal » Major
Refineo’s picture

This issue still exists in Drupal 7.14 and Views 7.x-3.x-dev.
I notice this when my test users have multiple roles or access settings are set for multiple roles.
For the time being I use the workaround from #29.

Scenario A
I have 2 pages (cloned) in a view: both pages have access type set to Role.

Page 1 access settings set to role: administrator

Page 2 access settings set to roles: anonymous user, authenticated user

What page should be displayed in this case for the administrator role ? (administrator is also the authenticated user and can see all views).

Scenario B
I have 2 pages (cloned) in a view: both pages have access type set to Role.

Page 1 access settings set to role: visitor (custom role)

Page 2 access settings set to roles: anonymous user, authenticated user

What page should be displayed in this case for the visitor role ? (visitor is also the authenticated user).

vsavovski’s picture

As far as I can see, issue still exists. But if you create a master display without specifying access control, later when creating other displays you can override access per display no matter if you have more than one display of the same type.

Tested with two page and one embed display all having different access control managed via different permissions.

mattsmith3’s picture

I can confirm the issue. You have to change the access type for the override to stick.

HansKuiters’s picture

I can confirm the workaround in #32. Delete (if set) the access control in master and then create access settings in each display. Tested in 7.x-3.5, not in dev.

marameodesign’s picture

I can also confirm the workaround in #32 works perfectly.

kidfgrk’s picture

Assigned: Unassigned » kidfgrk

I can also confirm the workaround in #32 works perfectly.

malcomio’s picture

Yes it is possible to achieve the desired result with this workaround. To clarify, the steps I took were:

  1. Create a display and an attachment to that display
  2. While editing the attachment, click Access: Permission
  3. Set to override for this attachment (I left this as permission-based access)
  4. Set the permission to use for access
  5. Save the view
bhans’s picture

This just started to happen to me with views 7.x-3.7. Changing permission type allowed to get around.

jetwodru’s picture

#16 suggestion worked, thanks

jetwodru’s picture

#16 suggestion worked and solved my issue #2177101-3: Very Obvious Bug In Access Permission (This Page Override) ?, thanks

joachim’s picture

Priority: Major » Critical
Issue summary: View changes
Issue tags: -override-problem

Updated the issue summary to have steps to reproduce & workaround.

Also upping to critical, as this can easily lead to an admin user lowering the access permission on a view.

John Pitcairn’s picture

Ouch, this one just bit me hard. Very unhappy client. Workaround is OK for me.

rooby’s picture

I recently got bit by this too.

Workaround works but often your permissions get broken before you realise you need the workaround (luckily for me it was pre-launch) so a fix is mucho needed.

John Pitcairn’s picture

We exposed a lot of private data for about an hour. Scary.

dagmar’s picture

Assigned: kidfgrk » Unassigned
Status: Active » Needs review
FileSize
3.15 KB
FAILED: [[SimpleTest]]: [MySQL] Failed to run tests: tests were executed, but no results were found. View
5.02 KB
FAILED: [[SimpleTest]]: [MySQL] Failed to run tests: tests were executed, but no results were found. View

I tested #14 and worked for me.

Patch provided in #14 doesn't apply anymore. Rellolled and added test.

The last submitted patch, 45: views.1174588-test-only.45.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 45: views.1174588.45.patch, failed testing.

dagmar’s picture

Status: Needs work » Needs review

The last submitted patch, 14: 1174588.patch, failed testing.

Kcannick’s picture

This seems like a pretty significant bug which could easily lead to security breach. I had a view listing subscribers Names, Phone numbers, emails and mailing addresses exposed for who knows how many people to access. I'm surprised that this issue has not been resolved in nearly 4 years.

duckx’s picture

having the same issue too. i have 2 page views. one is supposed to be a private view and one is a public view. when i switch to the public view page and set the role to override and give access to anonymous users, it also affects the other private view page. one solution is to separate the views, but thats unnecessary bloat i think.

lunk_rat’s picture

I also ran into this. @duckx see the workaround in the original issue summary above:

If you first override the access control type ("Permission" or "Role"), you can then override the corresponding settings for that particular access type.

I almost resorted to creating a separate view (really inefficient) but then found this issue and the workaround solved it for me.

doppel’s picture

I also encountered this problem by creating a view page and added 2 extra pages
PAGE A set to ACCESS: ROLE - ROLE 1
PAGE B set to ACCESS: ROLE - ROLE 2 with OVERRIDE THIS PAGE
But then when I went back to PAGE A, ACCESS: ROLE was also been changed to ROLE 2.
PAGE C set to ACCESS: ROLE - ROLE 3 with OVERRIDE THIS PAGE
But then when I went back to PAGE A and PAGE B ACCESS: ROLE was also been changed to ROLE 3.

That was weird but then I solved my problem with the work around.
What I did was this,

I went back to
PAGE A set to ACCESS: ROLE - ROLE 1 with OVERRIDE THIS PAGE
then go to
PAGE B set to ACCESS: ROLE - ROLE 2 with OVERRIDE THIS PAGE
then go to
PAGE C set to ACCESS: ROLE - ROLE 3 with OVERRIDE THIS PAGE

That solves my problem.
Hoping that a patch will be available soon.

Regards,
PAGE B set to ACCESS: ROLE - ROLE 2 with OVERRIDE THIS PAGE

dagmar’s picture

As a note. The patch from #45 should fix this issue, but you see it in red (test failed) because the test are broken for views 7.x-3.x from a long time.

Zarevac’s picture

Any updates on a fix? I just lost a couple of existing Views after I edited them as I was unaware of this. The workaround doesn't do work for me so I am gonna create double Views. Something else I was wondering, did anybody try to export/edit and then import to see if this jimmy rigs it?

mohsinkhanmca’s picture

SOLVED
In My case I have to set permissions based on multiple Roles. So I have set access type to roles.
Click on the role link then change all displays to this page override, do this for all sub views and then change the option in my case I have to set permissions for multiple roles. CHEERS :)

Charles Belov’s picture

To clarify, it took me some thinking to parse the workaround, so I'm putting it here for whoever needs it.

Given: I want to restrict a particular view to certain roles, but the roles vary by view page.

Steps:
1. Set Master to restrict by Permission/Administer Views
2. Set Page 1 to This page (override), Role, roles for page 1
3. Set Page 2 to This page (override), Role, roles for page 2
4. Set Page 3 to This page (override), Role, roles for page 3

sonicthoughts’s picture

Issue tags: +needs security review

Wow - Im curious why this hasn't shown up as a security issue. Typically changing view access is due to security/privacy concerns but this seems to globally make changes to all displays. I certainly got bitten.... Anyone know procedure to report as a security issue?

rooby’s picture

graceman9’s picture

Thanks #56! Works for me.

prafull.addweb’s picture

Issue tags: +views
Alireza Tabatabaeian’s picture

5 years past and the problem still exists. the only solution I found was to use two separated view. none of the answers worked for me.

Alireza Tabatabaeian’s picture

One trick could be : "Set access to None" , then in different pages using contextual filter, user role can be checked manually

JamesRobertson’s picture

The work around suggested at the top works for me... Drupal 7.54