How can I manage the “Open with Explorer” button based on user permissions?

Question

I would like to disable the "Open with Explorer" option in my SharePoint 2010 sites based on user permissions.

Basically only those users with Full Control should have the option of using the "Open with Explorer" feature. I ran across something that said OwE was dependant on the "Browse Directories" permission, but after disabling that permission for Contributers OwE was still working for them.

Is there a way to restrict the use of "Open with Explorer" with permissions?

Edit: This blog post has a detailed explanation of how to change the permission that Open with Explorer needs. This is pretty much exactly what I want, since I can reassign OwE to use a permission that only Owners have. So now I have a new question in addition to the previous one: Is making changes in the 14 hive like this safe enough to carry out on a production server?

Answer 1

First off: you really should create a new question!

Regarding your question, it is never a good idea to change "Microsoft" files. Every time you patch your farm you risk your customisation is overwritten, and usually this kind of customisations is unsupported.

You could use custom actions to remove the original link/button to open with explorer (much like described here for Open in Windows DataSheet View) instead though

Answer 2

You can put in an audience targeted (permissions) script editor web part in your page. The script editor web part will be a css injection on the page. So you can find the css class that is responsible for the open with explorer button and apply the display none property to it.

Here is a a list of the css classes for the ribbon: http://sharepointexperience.com/csschart/csschart.html

Answer 3

Since I framed the question this way, the answer is that the button in the Library ribbon for "Open with Explorer" is dependent on the permission:

Use Client Integration Features
Use features which launch client applications. Without this permission, users will have to work on documents locally and upload their changes.

The file C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATES\DefaultTemplates.ascx contains the information which indicates what permission that button needs in order to be active.

I found this out by reading this blog post.

Answer 4

I have made my case that your proposed solution of disabling Client Integration is too heavy handed. I will make a few suggestions for you that you may consider to mitigate the chance of accidental deletion. In my company's sites we have a policy that only site owners have delete permissions. Other people who need contribute permissions are granted a special "contribute-no delete" permission set. We do have a few lists and libraries that are mission critical where the owners have requested that we put a policy to prevent accidental deletion. To do this we created a check box column called "Allow Delete" and attached an event receiver that specifically checks that the field is checked before allowing deletion. This field is hidden in all the views except for a special one called "Delete Items". The site owners then have to take three steps to deliberately delete items. The have to select the view, check the "allow delete" field save the changes to the field (inline editing is enabled) and then select the items and delete them.

I promise you that if you disable Client Integration on an entire site collection you will drive down user acceptance and users will find ways around using SharePoint. If you do not feel comfortable with implementing any of these suggestions I would be more than willing to give you a hand to the best of my ability.