Compatibility issue: We currently overwrite other user_has_cap filters.

[joryhogeveen]

Compatibility issue: We currently overwrite other user_has_cap filters.

[pbiron]

Thanx for addressing this.

For others, the underlying issue is as follows:

when VAA is run in a multisite environment and the current user is a super admin, if some other plugin has hooked into user_has_cap and the hooked function modifies a user's capabilities based on that users role, then that function hooked to user_has_cap never gets called when "Viewing as role"...because WP Core's WP_User::has_cap() short circuits when the current user is a super admin.

[JoryHogeveen]

@pbiron

Please check the latest dev branch for the fix!
https://github.com/JoryHogeveen/view-admin-as/tree/dev
PR: #54

I actually did what I proposed above (and I now see you proposed something quite similar in your plugin comments).
You can review the changes in the PR.

It's way more logical to run the user_has_cap filter at the beginning so all other plugins can run their filters based on the modified user. (I actually make temporarily changes to the current user when viewing as a role or with modified capabilities).
I've also applied the user_has_cap filter within the map_meta_cap filter to make sure these capability changes apply here as well for super admins.

Thanks again for your input.

[JoryHogeveen]

Already found the first issue.

When you are not a super admin but this plugin is still activated through the view_admin_as capability "Restrict User Access" overwrites our the full list of capabilities (priority 9).

Related: intoxstudio/restrict-user-access#11

[JoryHogeveen]

@pbiron
If you have the time, please confirm the current dev branch status fixes your problem 100%.
1.7.2-rc1 is done.

PS: Since it's related, what is your opinion on #53?