Delete this site

No, this is not a request for the Live Spaces administrators to follow through on, this is going to be a post about the ‘Delete This Site’ link, or more aptly, the DeleteWeb custom action within SharePoint, on the Site Settings page.

Yesterday, during my session on developing custom actions within SharePoint at SharePoint Saturday Boston, my third demonstration was on hiding custom actions, using the HideCustomAction element. My example was to hide the ‘Delete this site’ action found under Site Administration custom action group, on the Site Settings page, as shown below.

I’ve had to deploy this solution for several clients in the past, where they have given full control of sites (webs) over to one or more people, to help manage a large deployment. However, on more than one occasion, the sites themselves have been deleted, “accidentally”, even though when you go to delete a site in SharePoint, you are prompted to confirm this action, without any confusing ‘Yes or No’ buttons, only ‘Delete’ and ‘Cancel’, which, in my humble opinion, is just about as straight forward as you can be.

So, during my demonstration, someone had asked if this prevents users from accessing the DeleteWeb function entirely, so sites cannot be deleted at all. No, this only hides the link to the site. If the person knows the URL by remembering it, googling it, or, now, reading this blog post, by going to http://www.intranet.net/sites/subsite/_layouts/deleteweb.aspx, and they have permissions to delete the site, they can definitely still delete it. What we are doing here is just removing it from their field of view, or “security through obscurity”. What I also did in the code (available on this blog post) was keep the feature hidden, so it needs to be activated from the server via stsadm, so the site administrator, if they were to check the site features and see a feature called Hide Delete This Site Link From Bob or something similar activated on the site, they could then just deactivate the feature, and be on their way to deleting it. Again adding and extra level of protection on that function.

Another question came up – if sites are deleted, do they go to the recycle bin? No, they do not… out of the box that is. I also mentioned that Microsoft IT had posted a project to Codeplex, which creates a solution for this. Their utility, found here at http://codeplex.com/governance, is called Microsoft IT Site Delete Capture. This is a great solution that I have deployed for numerous clients, captures the contents of the site on the server itself, and stores it away in an administrator defined location, for later restoration… this beats trying to load a site from a backup tape, then the site can be restored afterwards. This makes use of the SPWebEventReceiver.SiteDeleting method. If you wanted to take this a step further, you could modify the event receiver (which Microsoft IT has posted on the above mentioned Codeplex site here), to look at what user is deleting that site, see if they are, say, a site collection administrator, and then let them delete it, or, if they are not, do not let them delete it, and fire off an email, or log entry in the system event log or ULS logs, stating that Bob tried to delete his site again, even after the intensive training we gave him last week on just that subject.

And another question that came up on this topic during my session – can you assign rights, as you can for the CustomAction method, to the HideCustomAction method, so it is only visible to those that should see it – no, you cannot, however, I would recommend you hide the existing DeleteWeb action, and then replace it with your own DeleteWeb (however, it should not be called DeleteWeb, as that is already being used OOTB) action, which you then give rights to, using the Rights attribute of CustomAction, with any of the possible values in Microsoft.SharePoint.SPBasePermissions, however, there is unfortunately, not a "SiteCollectionAdministrator” SPBasePermission you can assign, but maybe your site collection administrators are the only ones with ApproveItems,UseRemoteAPIs,DeleteVersions permissions, and then you can really pick out who is who to make that link visible to.

I hope this helps and gives a little more detail and clarity on what was covered yesterday at SharePoint Saturday. I welcome any more questions on the subject, just leave a comment!