Assume the following situation: You have a Project Web Access site (PWA) on your Project Server that has the SharePoint Server Publishing feature activated both on the site collection and on the site level. This detail might seem to be irrelevant now, but gets an importance pretty soon. The permissions on the PWA are customized and rather restricted, even project managers have only Read permissions on the root site level. The PMs complain often, that they can not open the project from the Project Detail Pages (PDP) for editing, the corresponding buttons are inactive on the ribbon.
Image may be NSFW.
Clik here to view.
The administrators check the project and see, that it is checked out to someone else.
Problem: the administrators see the status information on the PDPs, however other user do not. For example, if an administrator opens the project for editing, the following screen is displayed:
Image may be NSFW.
Clik here to view.
The users with standard rights see however only this, without the status bar:
Image may be NSFW.
Clik here to view.
I found, that the content of the status bar is contained in a DIV with id="pageStatusBar" on the web page. There are several JavaScript methods, that manipulate this content, like addStatus, appendStatus, removeAllStatus, removeStatus, setStatusPriColor (all of these in init.debug.js). After setting breakpoints in these methods, and reloading the site, I found, that the status bar is displayed temporally in each cases, but it is hidden then for standard users, via a JavaScript method that is included in the PDP itself (like Schedule.aspx):
document.onreadystatechange=fnRemoveAllStatus; function fnRemoveAllStatus(){removeAllStatus(true)};
For the administrators, this script was not included in the page, and so the status bar remained visible.
After a search using Reflector, I found the very same script block being inserted to the page by the HideStatusBar method of the PublishingRibbon class (namespace: Microsoft.SharePoint.Publishing.Internal.WebControls, assembly: Microsoft.SharePoint.Publishing, just as any other classes below). This method was called by the HideRibbonAndStatusBarAndSiteActionsMenu method, which is called by the OnLoad method of the same PublishingRibbon class, if the CanShowSiteActionsMenuItems method of the ConsoleVisibleUtilities class returns false:
public static bool CanShowSiteActionsMenuItems
{
get
{
SPBasePermissions permissions = SPBasePermissions.BrowseUserInfo | SPBasePermissions.CreateSSCSite | SPBasePermissions.CreateAlerts | SPBasePermissions.UseRemoteAPIs | SPBasePermissions.UseClientIntegration | SPBasePermissions.ViewVersions | SPBasePermissions.OpenItems | SPBasePermissions.ViewListItems | SPBasePermissions.ViewPages | SPBasePermissions.Open | SPBasePermissions.ViewFormPages;
CombinedBasePermissions permissions2 = new CombinedBasePermissions();
If ((((permissions | permissions2.ListItemPermissions) == permissions) && ((permissions | permissions2.ListPermissions) == permissions)) && ((permissions | permissions2.RootSitePermissions) == permissions))
{
return ((permissions | permissions2.SitePermissions) != permissions);
}
return true;
}
}
The CombinedBasePermissions is a helper class that aggregates the site and list permissions of the current user from the current SharePoint context.
The value of the permissions variable is a combination of several list- and site-level base permissions. If you compare it with the standard Read permission level (see the next two screenshots below), you can see, that it is exactly the same combination of permissions:
List permissions for the Read permission level
Image may be NSFW.
Clik here to view.
Site permissions for the Read permission level
Image may be NSFW.
Clik here to view.
We compare the site and list permission returned by CombinedBasePermissions with these predefined set of base permissions. In the case of the PDPs we have no list context, that means, only the site permissions will be compared. If the current user has no permission beyond the ones included in the standard Read permission level, the remove script will be injected into the page, and the status bar won’t be displayed for the user.
The following screenshot illustrates the site permissions for the Team members (Microsoft Project Web App) permission level:
Image may be NSFW.
Clik here to view.
It includes the Browse Directories and the Edit Personal User Information base permissions. If the user had the Team members (Microsoft Project Web App) permission level either with or without the Read permission level, they would like to see the status bar. However, granting extra permissions to the users might be not desired on one hand, on the other hand, its effect would not be limited to the PDPs, the relevant status bar would be displayed on all other pages as well.
You can consider, I you really need the SharePoint Server Publishing feature. If not, deactivating it on the site level might solve the issue as well.
If you are OK with a quick and dirty solution, include the following script in you PDPs, for example, via a Script Editor Web Part:
<script type="text/ecmascript">
function removeAllStatus(b) {
}
</script>
The script overrides the default implementation of the removeAllStatus method in the scope of the page it is included into, and makes it impossible to hide the status bar.
As the result of the page customization, that status bar left displayed for standard users as well:
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
