Provide an option to disable the "Share" button.
The Share button breaks inheritance on an item, and without warning to the user. With the default Permission Level of "Edit" in Team Sites, you can quickly have 100's or 1000's of items with unique permissions. Going forward, any permissions granted at the library or site level can create a situation where new users will see all of the content in a library, except for those with unique permissions.
I would like to be able to disable (hide) the Share buttons at various tiers such as library, site, site collection or web application/tenant.
Even an indicator in list view for items with unique permissions will help.
Sean Megley commented
Client wishes to remove Share button and especially displaying the Shared with information.
+10 to Mike's Idea
Anthony K commented
Microsoft, any update on this highly voted item? Some statement on your position would be nice.
+1 to Matthew Cook's suggestions.
Matthew Cook commented
I suggest SharePoint by default:
1 ) separate the concepts of sharing and permission changing. If a user without user management permissions tries to share with a user without permission, they should receive a warning that they can't do that, and an option to request a permission change from an admin. Users who have got user management permissions should be warned that particular users will get permission to be able to have the file shared with them, and be given the option not to grant it.
2 ) have permissions be additive down the directory/folder hierarchy. Items can still have their permissions explicitly separated, but it should require very high level permissions, and prompt a big warning box suggesting the information architecture be changed instead.
Any updates on this? Although not recommended can we just hide it from the end-users? if they don't see it they won't click it. Any security concerns on that? thanks in advance.
Chris Lathrop commented
Related to this is an issue with the Copy link functionality. Our testing revealed that for users with Read or Contribute permission copy link functions as implied (it merely copies a link), but for Site Owners the behavior is to automatically create a Sharing link which defaults to the tenant level setting (which may generally be Edit level permissions for all internal users - or a worse case of anonymous). Our observation has been that Site Owners do not notice this is happening and are inadvertently granting widespread edit access to anyone with the link when all they were trying to do is get a link to the document. Additionally, they are copying a link generally for the purpose of sending it in an email. Access to that link is then uncontrolled - creating a security problem - because users tend to do things like forward emails to others as they see fit.
Remco Spierings commented
The options to share files or even complete folders is great but users can also share a main folder and give access to the whole directory structure with all it's documents. I would prefer to have the option to disable sharing on certain folder levels like main folder - sub folder. Every folder under the 1st sub folder can be shared but not the main folder or 1st sub folder. This way user cannot share too much with others.
Paul Cooper commented
Absolute disconnect between governance and security. This is a serious defect.
Patrick Reeves commented
What everyone else said, with the added sauce that people without full control on a site or library, can give other people rights to files/folders in the site collection. This is a serious governance issue.
Anthony K commented
2.5 years later and still Microsoft is ignoring basic governance requirements it's customers are crying out for. Admins and site owners require the "option" to disable sharing, not just because of the dreaded item level permissions and how it can impact performance, but from a security and record compliance perspective. MS really needs to lift its game in governance because at the moment they are creating more ways end users can navigate around governance policies, and allowing unfettered sharing is a big issue. Sort it out Microsoft!
iVan Corbe commented
At the moment admins do their work granting people through groups and remove the option to share items through the different menus (Access request settings) this shouldn't be an issue. But at the moment there are unseasoned admins that don't know what these evil buttons do to the permissions structure the best option should be to enable a way to prevent the usage of the Sharing Links in a site collection or tenant.
SHARE should be a simple way to provide someone else with a link to the content. Users mostly do it to notify about a file just saved or even other things like getting the link to create a promoted link list.
All these usages corrupt the governance of the permissions structure and it is hard to say an user or a loca admin "Please, avoid using the Share Button in SharePoint, insofar you use it you will get a good permission tangle in the site and your files will get blocked..."
I think that:
• The naming and emplacement of the functions "Share, Alert, Copy Link" should be reviewed
• The good old option to copy the raw "clean" link showing the path should be re-enabled
• And of course, enable an option to disable the option to create more evil Sharing Links in a site collection or tenant.
This is definitely something that needs to change. There is a "Copy Link" button as well as Share. Share should only appear for a certain permission level (maybe for users who are allowed to change permissions), and the "Copy Link" literally just copies the direct link to the document without affecting the permissions.
The main issue is users have permissions to edit documents but they dont really know the consequences of sharing or copying links. It does become a management nightmare because even if a user has permissions to view and edit a document, inheritance breaks as soon as the user clicks on the link sent by Share/Copy Link.
This is a major issue with our permissions governance. Users don't understand that Sharing can break permissions inheritance and make them almost impossible to audit.
This makes it so difficult to have permission governance.
We also face this feature as a problem in our tenant. Most users think that "Share" is to notify someone about any update done; and they keep "sharing" the files with people who only need to be provided with the link to a file in the "old way" (not these cryptic links). Of course they could also activate the Alerts... but this seems to be too dificult for unskilled users.
A Jonathan Valdes commented
This suggestions will never be approved! you guys don't understand clearly the concept of this platform!.
Remember one important thing, this is a collaboration platform!
Define your security groups for REGULAR USERS and let users share with other folks freely after. increase the user adoption, and training.
Regular users will be members of security groups with access to everything (library or site)
Sporadic users will have access only to the folder or specific file using the SHARE button.
YES, share breaks the inheritance but as long you created your security groups, you won't have any issues, your security group will still there and for other folks the security won't be compromised.
In the future if you need to migrate, you will only consider folks that are under security groups and letting the other out on your migration.
Paula Hidalgo commented
Sharing read access to documents without granting access to the entire document library is desirable. The main problem with the "share" breaking inheritance is there is no easy way to report out on the SharePoint site where these exceptions exist or traceability on how changes were introduced. I agree with the comments about the permission model needing significant rework.
This does need fixing, but needs some granularity. I want people to be able to share pages / links and documents, but I want this to happen using existing permission groups by default. Just hiding the share button isn't the answer, allowing a site coordinator to dictate what sharing is allowed, IS the answer.