If you have customised the new button order and/or default content type for a list or library, then expect these changes to be lost if that site is moved. SharePoint Bug! You may have done this in order to change the content types that appear under a list’s new button or change the content type that used by default (i.e. when a user just clicks the new document icon rather than selecting a content type from the drop down).
A library with a restricted set of content types
As you can see in the image above, I have a library configured with a restricted set of content types available under the new button. After moving the site (using Site Settings > Content and Structure) these customisations are lost. See the next image.
The same library having been moved to a new location
So that’s the issue but what can you do to fix the situation if moving sites is something that you need to support regularly? Firstly, this isn’t the only issue you may encounter.
With the luxury of a farm solution this can fixed using a web event receiver. Using the WebMoving event you can store list new button order information (e.g. in a web property bag) and then in the WebMoved event, this information can be read and applied. I don’t have a code example of this as in my situation it was suitable to apply a static new button order to lists based on the site definition and list template.
If you are unable to deploy a farm solution (e.g. SharePoint Online) then this issue is more difficult to solve. I assume that you can write remote event receivers for web events and apply the same logic as above (I haven’t tried this). Otherwise I can’t think of another reasonable solution beyond writing a control with client JavaScript that ensures the new button order upon viewing the page. However this would require knowledge of what the new button order needs to be, and hence would be more complex to implement if users are free to change it.
When using Move Site via Site Content and Structure to move a site to another location in the site hierarchy you may find it fails with one of the following errors (depending on where you look):
Operation to Move 'old site URL' to 'new site URL' failed
"MoveWebs.Move catches SPException : The attempted operation is prohibited because it exceeds the list view threshold enforced by the administrator."
"Move Operation under site 'Site Name' failed in the Content and Structure tool. Details in ULS logs"
Increasing the list view threshold alleviates the issue however I have not managed to figure out exactly why the limit is reached. I have encountered this when none of the lists in the site being moved, or any of its child sites, have breached the list view threshold. In fact the largest list was less than 2000 items with the list view threshold at the default 5000.
Perhaps its due to the aggregated total items being moved? This makes some sense as the list view threshold is in place to prevent SQL table locks which occur when more than 5000 rows are queried. As all the lists in a site collection are stored in a single table it makes sense that the same limitation would occur here.
If moving large sites is something that you need to do, I would suggest doing it out-of-hours if possible as these thresholds are in place for a good reason. Make sure that you utilise the administration list view threshold rather than increasing the one which restricts the majority of users. Performing actions that require an increased list view threshold may cause serious performance issues.
Please comment if you have anything to add to this.
The following is a simple PowerShell script for attaching SharePoint web event receivers. It is clever enough to check if they have already been attached and hence to avoid duplication.
There are no “gotchas” or anything really worth noting here. This example is pretty much the same as the dozens of list item event receiver examples out there, just targeting a different event receiver type. I am only posting it because I was so surprised that I had to write it myself after failing to find an example to ‘steal’ from the internet – maybe I wasn’t looking hard enough.
The first half of the script is the bit you’ll be interested in (if you are interested in any of it!), the second half is just a usage example.
SharePoint allows developers to create receivers for the EmailReceived event which occurs when a list receives an email. I have a use case which requires me to leverage this event in order to forward incoming email to a set of users according to a number of business specific rules. To achieve this I must create a custom email message object (we are using aspNetEmail to send email) from the message object received in the event receiver. I need to be able to extract all of the parts from the SPEmailMessage to create this new object. The SPEmailMessage object is pretty easy to work with; the attachments are in the attachments collection, the subject is in the subject property – you get the idea. However, there is one ‘property’ that isn’t as trivial to extract from the object: a meeting invite.
I will explain how to extract the meeting invite below but first let me provide a basic overview of how an email is stored in eml format. The eml format is relevant because the SPEmailMessage can be constructed from an eml stream and also because when SharePoint is configured to attach incoming emails to discussion items it does so using eml. The first lines of an email in eml format are the email headers (think properties). These are simply key value pairs and includes things like ‘to’, ‘from’, ‘date’, ‘subject’ and many other less obvious properties including threading info. Then comes the mime body parts. These should represent the ‘same’ content in different formats (mime types). Typically this includes a text/plain block and a text/html block. A client which supports HTML will render the latter body part where otherwise it might render the plain text body part as the email content. Finally, attachments are listed out with their own set of headers and the binary content (commonly represented as a base64 encoded string).
When a meeting invite is sent to a SharePoint list without attachments the meeting invite itself can be found in the attachments collection of the SPEmailMessage object. But don’t be fooled. Although it is present in this situation, if you send same meeting invite with an attached document then – sad face – the meeting invite is not in the attachment collection (the attached documents will be). Nor can the invite be found in any of the public properties on the email object. It’s not that strange that meeting invite isn’t present in the attachments collection; it is strange that it can ever be found there. I say this because if we consider the eml format, a meeting invite is stored as another mime body part (of type text/calendar) and not as an attachment at all.
Eventually, after much investigation and reflection, we discovered a way to read the mime body parts directly from the email using only Microsoft libraries with the help of reflection. Once we have the meeting invite as a memory stream we parse it into a dictionary of string properties. The dictionary contains keys such as “LOCATION”, “SUMMARY”, “DESCRIPTION”, “DTSTART”, “DTEND” and “UID”, along with any other data stored as part of the invite. See the example code below:
Finally, I’d like to note that we only have requirements to support Outlook clients at this point so please consider that your mileage may vary when you get it out into the real world. Good luck.
In event receivers other than ItemAdding it is a simple task to determine if the current item is a file or a folder. You would write something along the lines of:
However in the ItemAdding event properties.ListItem is null. This is because the list item is yet to be created. In order to determine if the current item is a file, you should instead try this:
