Weird bug with a relatively complex D7 setup using admin_views: on the admin/content page, nodes of one content type ("event") don't show up at all, but only for a specific role ("editor"), even though this role has full access to this type of nodes (create, edit own/all, delete own/all).

If logged in as admin, the "event" nodes appear on this page as expected.

If logged in as editor, the "event" nodes don't appear at all; but nodes of other types show up just fine. Using the filter Type: Event, gives the "no content available" result.

If I give the editor role the permission "Bypass content access control", then the "event" nodes do appear again on the content page. But this gives the editor access to other types of nodes I don't want him to access...

If I disable the admin_views module, the problem goes away. (Editor is able to see the "Event" nodes on the content page again.) But since it's a rather complex site, the ability to customize the filters and columns on the content page is quite useful, so I don't want to disable this module.

Visiting the edition page for this admin view (admin/structure/views/view/admin_views_node), I don't see anything related to user roles, so I don't understand this behavior. I tried with or without Ajax, but no change.

I also tried to clear all caches and clear views cache.

Any idea what's causing this behavior?


After more tests, it seems that this problem is somehow related to the organic groups module, which is also used on this site.

Some content types are intended (configured) to be part of a group, while other content types (such as "Event") are "group-neutral" (not part of a group; they don't even have the field for that). I have configured the node admin view so that users are able to filter nodes based on the name of the group they belong to (obviously this only applies to content type that can be part of a group, but it's OK). For this purpose, I have added the Entity Reference: Groupe relationship to this view, which then allows to add an exposed filter based on the title of the group.

Removing this relationship solves my problem. But I still don't understand why this happens for one role only.

So in summary: for the "editor" role, the view behaves as if this relationship is required (although it's not the case, I checked in the settings for the relationship), which results in all nodes not part of any group being excluded from the results.

I'll just remove this relationship (and related filter) for now, as I don't really have time to research this further at the moment...

  • If this is proven a bug you'd better report it to drupal.org, otherwise must be something wrong with your configuration settings. I don't think would be easy to reproduce it here. What you can do is to install a vanilla drupal place your roles/permissions and start testing.. – mchar Feb 23 '17 at 8:31
  • Thanks. I might report it to d.o indeed. I was asking the question here in the hope that someone encountered a similar behavior and/or had some suggestion. But the case is so specific that I fear trying to replicate it on a vanilla installation would take a lot of time. – s427 Feb 23 '17 at 9:55
  • Just some things that come to mind: - Are you using latest version of admin_views? - Does it also occur with the latest dev version of admin_views? - If you you made any customizations to the filters of admin_views, what happens when you reset them to the default state - Is there any value set in the filters that causes no events to show up. e.g. Is there perhaps any value set in the author filter field that causes no events to show up (because there are no events created by e.g. admin) – undersound Feb 23 '17 at 12:41
  • Yes it's the latest version (1.6), but not dev. I will try to upgrade to dev, to see if it changes anything. The only changes I made to the filters of this view are exposed filters, all empty by default; and the user who reported this problem to me is precisely the author of most "event" nodes, but she doesn't see them either... Still, I'll try to revert this view to its default settings to see if it changes something. – s427 Feb 24 '17 at 11:50
  • Reverting the view to its default state solved my problem, so it's not an admin_views issue. After more testing, I have determined that it is caused by a relationship that I had added to the view --although I still don't fully understand what is going on. I have updated my question with more information. – s427 Feb 24 '17 at 15:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.