AJAX fails due to hardcoded permission

Ah good, glad I wasn't going crazy and someone else is seeing this. In my case I'm using the Views Autocomplete Filters module and that had stopped working in my System display views since upgrading to 7.x-1.7. Thanks for tracking down the permission in question.

The only way the AJAX autocomplete functionality is available now for any System display views is for roles that have the "access administration pages" permission (aka "Use the administration pages and help") or alternatively, the Views "Bypass views access control" permission set.

I came across this too. I looked at enabling the extra permission - but those opened up too many admin pages for our users. Instead - as a temporary workaround for now - I've simply disabled the AJAX option in the system view definition. Slightly slower UI - but no worries of users accessing things we'd rather not... I had to do the same for the admin/content view also.

A quick and dirty way to disable AJAX on admin views, if you have many websites to maintain:

drush ev "foreach(db_query(\"SELECT d.vid, id, display_options FROM {views_display} d JOIN {views_view} v ON d.vid = v.vid WHERE tag = 'admin'\") as \$record) {\$options = unserialize(\$record->display_options);if (isset(\$options['use_ajax']) && \$options['use_ajax']) {\$options['use_ajax'] = 0;db_query(\"UPDATE {views_display} SET display_options = :options WHERE vid = :vid AND id = :id\", array('vid' => \$record->vid,'id' => \$record->id,'options' => serialize(\$options),));}}" && drush cc all

Thank you for reporting this.

We have just updated a bunch of sites and will definitely use the quick and dirty way before they start emailing things aren't working.

One question though: Is this something will get solved in subsequent versions or should we simply disable Ajax for all admin views for users that we don't want to have "Use the administration pages and help" or "Bypass views access control"?

Thanks again!

I am having the exact same issue with my users as well. Hope someone will be able to assist.
Thank you in advance.

Hi,

Here is quick patch for the dev version to at least uses a custom permission. I'll upload the patch for the 7.x-1.7 version soon.

Here is a patch for the 7.x-1.7 version.

Rerolled after #2411193 was committed.

Committed. Thank you all.

This patch works as a work around to fix this issue for everyone that updated to the secure version. But for a long term solution, should we not try to use the access control defined in the view configuration?

@fprevos2: Let's handle that in a follow-up issue.

I have updated to the dev version but I'm still seeing this problem on /admin/people. Our Membership Secretary, who only has admin permission for users, can no longer filter the view to find particular members.

Anyone have any ideas? Is this a separate bug or have I misunderstood that the dev version is now patched?

Hmm, there's something I'm not getting here. I can see that the code implements hook_premission() but I can't find that permission anywhere on the permissions page. Where should it be? Under Views?

I've loaded the permissions page, opened the page source and done a search for 'ajax' and the new permission is definitely not there. Any idea what I might have done wrong?

I've put a Devel dd() call into admin_views_system_display_views_permission() but it appears that, when I go to the permissions page, this hook is not being called for some reason.

I've now got the new permission to appear on the permissions page but to do that I had to change the name of the hook from

admin_views_system_display_views_permission()

to

admin_views_system_display_permission()

Can anyone explain to me why the original name has the '_views' included in it?

Are you kidding me?

Sorry, that was my fault, when I moved the change to the admin_views_system_display submodule I didn't rename the function correctly.

I thought I was going mad for while there. :-)

Committed. Thank you coranda.

Thanks for you help!

Thank you @fprevos2. #10 worked for me in D7.

Ah, glad this is a known issue and a fix is already committed. Thanks! Now a tagged release would be icing on top :)