Group access doesn't work in Views.

Created on 23 November 2023, about 1 year ago
Updated 28 December 2023, 12 months ago

Problem/Motivation

Tempted to put this as a bug as i am sure it does work but not as it should.

This is simplest case i can think of:
- i have a group admin and group members
- i have a content type called Policy
- member A has (authored) 2 Policies: nonGroup, inGroup
- make a simple view which lists the titles of policies with contextual filter on uid
- add page at user/%user/policies

in Group Permissions, admin has view access to entity (and relation) of any. There is no view permission of OWN; so haven't set anything for members.

When i go to the page user/[uid]/policies where [uid] is for member A, as these users, this is what i see:
- site admin: sees both policies
- member A: sees only nonGroup
- group admin: sees none

Both the member and group admin results are incorrect.

If i disable sql rewrite on my view, then, of course, everyone sees everything (but also wrong).

What should happen:
- site admin: sees both policies
- member A: sees both (because author)
- group admin: sees only inGroup

I did see a post related to this where someone explained a complex view with 4 relationships to get this to work. I tried that, it also did not work (and shouldn't be required).

Is there something missing here? Or does this simply not work? If it requires a slew of relationships to make this work, is there some sort of documentation on how to set this up? Does this work differently/better in the 2.x branch (as we'll be migrating to this soon)?

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

💬 Support request
Status

Active

Version

1.6

Component

Code

Created by

🇨🇦Canada liquidcms

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @liquidcms
  • 🇨🇦Canada liquidcms

    A little more detail.

    - with Group Admin set to View Any, the Admin can see the actual Policy nodes; but they do not show on the view (a Views/Group bug)
    - there is no View Own so not possible to set this for the member, but they do not have access to their own group nodes (Group bug)
    - setting Member to View Any and it then matches the Group Admin: can no see own node pages but items do not show in the view.

  • 🇨🇦Canada liquidcms

    I am able to get close by adding the Content Access module (because Drupal doesn't provide View Own permission) and this patch for Group to provide View Own: "View own" permission Needs work .

    Now, members can see their own content (both in/out of group) and group admin can see only member content which is in the group. Perfect. But my view for listing the content still shows nothing for the Group Admin. I can see the view page but no titles are listed. But at this point i guess this is more of a core/views issue than a Group issue, isn't it?

  • 🇨🇦Canada liquidcms

    My solution so far to extend upon what is listed above is to remove SQL rewrite from the view (which then gives group admins ability to see more items than they have access to) and then added a views_pre_render hook to remove items from the list which do not have node_access. This works and mostly completes what i am trying to do here (limit views list and node access the same) but it does break paging.. so possibly a cleaner solution?

  • 🇳🇱Netherlands Jan-E

    I had a similar issue where a group member could add, view, edit and delete group content, but still the content did not show up in my view of the content. 'All entities' did show all group content (and users) of the group. All entities is no View:

    'Reflectie form' is a group content type that I created mid 2022. 'PMTO Sessieformulier' I added this month. Whatever I tried the first one shows up in views and the newer content type does not. See the Nodes:

    My own group content view did also only show the oldest content type, not the recent one. So I went looking around for similar issues and saw your remark about disabling SQL Rewrite. That finally did the trick!

    I do not have to filter out content that should not be seen, because it is a group/subgroup/subsubgroup structure. Every member of the subgroup or member of a higher group with inherited rights is allowed to view all subgroup content.

    But I am still at a loss why 'PMTO Sessieformulier' does not show and 'Reflectie form' does not. All recent group content types fail to show up, the older ones work as expected. Hints where to look are eally appreciated.

  • 🇳🇱Netherlands Jan-E

    Disabling SQL rewrite works OK, but I can only use it in Views on pages that are prohibited for people without enough rights. My site has a view on the frontpage showing 'Your content items' for the current user. As administrator (and a view that has an exposed filter on user) I can see all the content that the user has created:

    But the user sees this in the 'Your content items' view:

    'Video' and 'Reflectie form' are Group content types that I added mid 2022, bit the group nodes were added this month. 'PMTO Sessieformulier' and 'PMTO Gezinsformulier' are new Group content types. The Views show the content item in descending order of changes in the node. The user has exactly the same permissions for all content types. That is for the content type itself, but also for the group plugins (/admin/group/types/manage/--type--/permissions).

    In #2 💬 Group access doesn't work in Views. Active you said:

    setting Member to View Any and it then matches the Group Admin: can no see own node pages but items do not show in the view.

    Both screenshots above are of a View. But in groups v.1 with a God-like admin the admin stiil can use Views to access all nodes. Bewilering are the differences between the old content types and the new ones.

    This really is a nasty bug. @kristiaanvandeneynde or @dww Do you have any hints how to debug this? I am out of ideas.

  • 🇳🇱Netherlands Jan-E

    Disabling SQL rewrite in the 'your recent group content' view is no problem, because the access check in that view is done by comparing the uid of the current user with the uid of the node author. The real challenge is a view with all recent content for users that are member of a few groups, not all. There are 9 groups at the moment in my site. One user is supervisor of 4 of the 9 groups and should see only the recent group content in those groups. I tested disabling SQL rewrite in the 'all recent group content' view: the effect was that the recent content in all groups showed up. Clicking to see the details of a node like that gives a 'not authorized'. But the view already revealed far too much. I had seen that behaviour before at a lower (subgroup) level and developed a special field that shows 'No access' (Dutch: Geen toegang). That could lead to views like this (if you know the URL of that page):

    Fine at the lower level but no option for the recent group content at the frontpage. So I am forced to use a View with SQL rewrite and access checks. This view shows all recent additions to older group content types like 'Video', 'Document', 'Reflectieformulier'. But does not show new nodes for the new group content types: 'PMTO Sessieformulier' and 'PMTO Gezinsformulier'. On restricted pages like '/group/*' I can disable SQL rewrite, because I do not need node or group access working at that level. Groups correctly grants or denies access to group nodes.

    In fact I decided to merge 'PMTO Sessieformulier' into 'Reflectieformulier'. They have a similar function and as 'Reflectieformulier' (still?) correctly works in SQL rewrite disabled views, I can use that group content type to display one of the 2 field sets when adding and editing. Clumsy, but a workaround at the moment. So the only remaining problem for now is that new nodes of 'PMTO Gezinsformulier' do not show for anyone but the author at the frontpage. I fear the moment that new group content types have to be added to the site.

  • 🇳🇱Netherlands Jan-E

    My solution so far to extend upon what is listed above is to remove SQL rewrite from the view (which then gives group admins ability to see more items than they have access to) and then added a views_pre_render hook to remove items from the list which do not have node_access. This works and mostly completes what i am trying to do here (limit views list and node access the same) but it does break paging.. so possibly a cleaner solution?

    .
    Disabling SQL rewrite and adding a direct ffilter with group membership would restore paging. But then we are adding our own group content filters, while the Groups module should do that for us.

Production build 0.71.5 2024