Here’s a small fix for which I didn’t have time to investigate more properly:
Issue
The User Profile Page of another user shows a link “Add as colleague” when that user isn’t already a colleague:
It seems however that the link behind “Add as colleague” directs to the Default AAM URL rather than the current URL you’re using.
Example:
| Zone: Default |
http://internalserver
|
| Zone: Intranet |
http://intranet
|
When browsing to the page using http://intranet the link will refer to http://internalserver. This is not the desired behaviour (think mixed authentication or extranet scenario’s).
Quick fix using jQuery
<script type="text/javascript" src="/my/Style Library/js/jquery-1.7.1.min.js"></script> <script type="text/javascript"> $(function() { var el = $('.ms-my-addcolleague'); if (el.attr('onclick') != undefined) { el.attr('onclick', el.attr('onclick').replace('http:\\u002f\\u002finternalserver:80', '')); } }); </script>
I’m referencing jQuery in the Style Library of the My Site Host, which you need to add or modify the link. I’ve hardcoded the internal URL (default zone public URL), might be better to look that up dynamically but as said this is a quick fix.
You can view the source of your own User Profile Page to find the internal URL for your environment.
You can add this in a Content Editor Web Part to the User Profile page and it should work just fine making the link relative.
Applies to
I’m seeing this issue in a SharePoint 2010 + Service Pack 1 + August 2011 Cumulative Update (14.0.6109.5002). Might be fixed in a later CU or SP.
SharePoint 2010 and SharePoint Online (Office 365) allow for custom development in the form of Sandbox Solutions. Your code is restricted to a subset of the SharePoint API but allows you do most regular operations inside a Site Collection.
Problem
Here’s a scenario that fails every time and everywhere:
- Create a sandboxed Event Receiver that is registered to ItemUpdating
- Create a sandboxed Web Part that does an SPListItem.Update() from the SharePoint Object Model
- Watch how the sandbox errors out with the following message
[SPUserCodeSolutionExecutionFailedException: Unhandled exception was thrown by the sandboxed code wrapper's Execute method in the partial trust app domain: The sandboxed code execution request was refused because the Sandboxed Code Host Service was too busy to handle the request.]
- Now just edit the item from the SharePoint UI and watch how that works wonderfully well
Sandbox Request Architecture
So what’s going on here ?
In light of this you might conclude that there’s no possible communication between two sandbox code requests (the Web Part and the Event Receiver). As good an explanation as any, so feel free to chime in.
Other things
Here are some other things I stumbled upon while researching this issue:
-
ItemUpdated is not affected and works fine
- You cannot make your “after” events Synchronous in a Sandbox as they won’t fire
- (Sandbox) Event Receivers can only be registered declaratively in the Feature XML
- The certificate checking issue (crl.microsoft.com) has the same error message, but is unrelated to this issue
- Triggering the update from non-Sandbox code works fine
Workaround
So how about we conclude with a workaround ?
In some cases you could use the “after” Event Receiver rather than the “before” Event Receiver, but isn’t really a sound solution.
The best option would be to rewrite the Web Part to run its code on the client, either through Client OM (ECMAScript or Silverlight), or the SharePoint Web Services.
http://msdn.microsoft.com/en-us/library/ff798452.aspx