When I add an Attachment display to a view, and set it's access to a specific role OR permission, the attachment display is shown regardless of the user having said role or permission.

Do Attachment views heed Access checking?

My setup is as follows:

1. A view with Two Displays (Defaults, and Attachment). Defaults outputs a list of nodes and has unrestricted access. The attachment is set to use the Draggable Table Style from the Draggable Views project to order the views -- and uses access to [supposedly] only display to Site Administrators.

2. The view is outputted via drupal views_embed_view('myView','defaults') in a template file.

Any insight is much appreciated!

Thanks,

~ Brice

CommentFileSizeAuthor
#5 views-attachments_access.patch751 bytesdawehner

Comments

brice-dupe’s picture

brice-dupe commented

I guess what I'm asking is if attachment displays are conditional -- e.g. access is checked against the attachment, not just the parent display(s) the attachment "attaches" to. This does not appear to be the case [hence the "bug" report], and I'd like to clarify if this is a BUG or Intended Behavior. Thanks!

~ Brice

esha’s picture

esha commented

same problem here - any insights yet?

brice-dupe’s picture

brice-dupe commented

I'm still waiting for a response from the package maintainers -- but as a "workaround" I recommend checking for user permissions/access in the main view template file. The output of attachments is available as $attachment_before|after therefore, I'm using something like;

// temporary workaround for conditional attachments!
if($attachment_after && user_access('Allow Reordering')) 
	echo ($attachment_after);

Of course this is not OPTIMAL as the view renders the attachment even if it is not going to ever display it....

merlinofchaos’s picture

merlinofchaos commented

Sorry, I should have replied. I agree, this is a bug. I've got a lot going on so I have not had the time to address this (and probably won't in the near future), but submitted patches will be considered. In theory it should not be too difficult to do an access check prior to running the attachment.

dawehner’s picture

dawehner
Primary language German
commented
Status: Active » Needs review
StatusFileSize
new views-attachments_access.patch751 bytes

here is a patch for 2.x

i tested it once with a role based access and it worked as expected.

brice-dupe’s picture

brice-dupe commented
Status: Needs review » Active

dereine,

Looks like a quite simple patch! Thanks for providing it.

dawehner’s picture

dawehner
Primary language German
commented
Status: Active » Needs review

it needs review, its more then active :)

did you tested the patch also?

brice-dupe’s picture

brice-dupe commented

Dereine,

The patch works as expected here. I have tested both role and [specified] permission access. Thanks!

dawehner’s picture

dawehner
Primary language German
commented

Awesome! Thanks for reviewing it. If you reviewed it, set the status to "review and tested by the community".

merlinofchaos’s picture

merlinofchaos commented
Status: Needs review » Fixed

Committed to 2.x and 3.x branches. Thanks!

Status: Fixed » Closed (fixed)

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

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Status: Closed (fixed) » Active

Not sure if I should re-open this or start a new issue, but this seems related...

I'm trying to do a views_embed_view() from a block in hook_block() and getting the same issue as the OP (blocks show fine and dandy while logged out even though access is set to the authenticated user role). I applied the patch but this did not seem to address the problem for me.

Does this logic need to be moved a bit higher in the chain so that it works for programmatic calls to views_embed_view() as well as attachments?

merlinofchaos’s picture

merlinofchaos commented

It's possible views_embed_view() does not check access. This may be by design, but I don't remember. I think that makes this officially a different issue, at least. =)

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Status: Active » Closed (fixed)

Cool. :) Will do, thanks!

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

New issue posted at #554016: views_embed_view() does not check access