This was a really annoying problem that arose in a site that had been migrated from MOSS 2007 to SharePoint 2010 using the database attach approach with no visual upgrade:
In 2007, starting from the ‘people’ page, where the members of a given group are listed, the normal flow of adding users goes like this:
Basically, starting from the People and Groups page, you add a user, then end up right back where you started.
However, for an upgraded site, the 2010 flow goes like this:
Rather than ending up where you started out, you are taken to the site Permissions page and do not end up back where you started. The user or users do get added – so everything works - but ending up on the permissions page is definitely confusing, and it could lead to the belief that adding the user did not work – or worse: that the you must now grant permissions directly!
So why does this happen? Looking closer at what is going on behind the scenes, in 2007 there is a ‘Source’ querystring parameter that is passed to the Grant Permissions page (aclinv.aspx) that tells it where to redirect to upon completion. Once the site has migrated to 2010, the source parameter is missing when the ‘Grant Permissions’ page is navigated to via the ‘Add Users’ menu. It looks like this parameter is missing because SharePoint 2010 sites using the version 4 master page (or version 4 compatible) do not need it, since the ‘Grant Permissions’ form is actually a scripted browser dialog. In other words, there is no navigation involved, so there is no need to worry about where we came from. I dove into the SharePoint 2010 out of the box client script to confirm this: It checks to see if the page is a version 4 UI, and if it is, the slick modal shows up overlaying the current page:
In the case where the v4 UI is not present – like a migrated site that has not undergone the visual upgrade – the script simply navigates to the Grant Permissions page, without the Source parameter.
The How To Fix Section:
This script will intercept the call and add in the source parameter to the URL. It actually adds the source parameter to EVERY url passed to the ShowPopupDialog method – in case there is another place where this kind of problem is happening. I suppose an improvement would be to add a check to see if the source parameter was already there…
<script type="text/javascript">
var _origShowPopupDialog = null;
try
{
if (typeof (ShowPopupDialog) == "function" && _origShowPopupDialog == null) {
_origShowPopupDialog = ShowPopupDialog;
ShowPopupDialog = ShowPopUpDialogPreUI4;
}
}
catch(e)
{}
function ShowPopUpDialogPreUI4(a) {
_origShowPopupDialog(AddSourceToUrl(a));
}
</script>- Add to master page. Make sure the system pages are all using that master page containing the fix script.
- Create a custom solution to wire it in via the AdditionalPageHead control. Here is a good article about this technique – where Jan Tielens is incorporating the jQuery library in the same way.
I did create a Visual Studio 2010 project that wraps this all in a nice site collection scoped solution – if there is any demand for it I will post it here.
