Second Life of a Hungarian SharePoint Geek

April 6, 2015

Make the Status Bar Visible on Project Detail Pages for Users with Read-Only Permissions on PWA with Publishing Feature

Filed under: JavaScript, Project Server, Security — Tags: , , — Peter Holpar @ 22:03

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

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

The users with standard rights see however only this, without the status bar:

image

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

Site permissions for the Read permission level

image

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

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

1 Comment »

  1. The same problem holds true not only for project server pages, but for pretty much all pages the Publishing ribbon is included. This is the first time I see someone digging as deep as me into the code, but same as you I didn’t find a good solution as there seems to be some weird permission checking going on.
    I actually resorted to injecting a JavaScript before anything else loads in a custom master page, capturing all status bar messages, waiting for the hide script to kick in a re-add all status bar messages. This was necessary because besides that nasty hide function there is also a function in there adding it’s own statusBar div into the page, so I sometimes ended up with two statusBar divs…

    I think the permission change is still the most valid. Browse Directories isn’t that bad in my eyes and only Edit Personal information is “more edit rights”, which again isn’t that bad if user properties’ permissions are set up correctly.

    Comment by Dennis Gaida — June 27, 2015 @ 19:10


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: