We’ve looked at the problems with this feature, so what can we do about it? Well the new Project Server 2007 eventing model isn’t broken, so if you have a developer handy use that!

First, uncheck the Workspace Permissions box in Server Settings / Project Workspace Provisioning Settings. Then, have a look at the WssInterop event WssWorkspaceCreated. This fires whenever, um, a workspace is created. The initial state of a created workspace is with permission inheritance broken and the service account assigned to the workspace with Full Control.

From here, use SPWeb.EnsureUser for each user you’d like to give access to the workspace. This works by adding the user to the SPWeb if they haven’t been already. This does not give the added users any permissions to the workspace. SPWeb.EnsureUser also works with Active Directory groups, so a model where every user needs read access can be simply accomplished. Finally, use SPWeb.RoleAssignments, SPWeb.RoleDefinitions, and SPRoleAssignment.RoleDefinitionBindings to assign users the correct permissions (sorry, hopelessly glossed over but there are examples out there on how to use these).

Something else to note about a custom solution is that despite unchecking the Workspace Permissions box earlier on, Project Server’s behaviour does not change when giving access to the PWA site. It will still handle this for you according to the rules in Part 1, leaving you to configure the permissions for the workspace with custom code.

This works fine and if you are able to make use of Active Directory groups, is fast as well. Plus now that you’ve gone custom, you have all of the freedom (and traps) of flexibility and the ability to create your own permission assignment rules. Don’t forget you’ll need to invest time in creating custom administration pages to manage those as well.

So what about going forward and sticking with the product for a solution? For Project Server 14 or 2009 or 2010 I have no idea if there will be any changes to the workspace permissions functionality. If you agree that this feature needs looking at, please give feedback to the Project Server team as they do read it and listen (I’ve had great responses from Treb Gatte and Brian Smith on other issues). Hopefully bugs will be fixed and the feature improved next release!

Thanks for reading and I hope this helps someone else out there with similar experiences.

If you’ve been having some great successes out of your Project Server solution you’ll probably be building up quite a few users and workspaces. One particular customer I’m aware of has over 1000 of each. To try and get around the inflexible rules outlined in Part 1, they’ve decided to give every user at least read access to every workspace. Unfortunately this has uncovered a particularly nasty SQL deadlock bug.

10/06/2008 15:33:59.86 Microsoft.Office.Project.Server (0x1540) 0x12C4 Windows SharePoint Services Database 6f8g Unexpected Unexpected query execution failure, error code 1205. Additional error information from SQL Server is included below. "Transaction (Process ID 151) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction." Query text (if available): "{?=call proc_SecAddPrincipalToRole(?,?,?,?,?,?)}"


The bug happens when one or more of the following operations is occurring at a time:

1. Creating a new workspace by publishing a project (queue job “WSS Workspace Create”)
2. Resynchronising workspace permissions from Server Settings / Project Workspaces (queue job “WSS Workspace Membership Synchronisation”)
3. Changing a user’s Project Server groups which results in changes to SharePoint permissions (queue job “User Synchronization for Project Web Access App Root Site and Project WSS Workspaces”)

When the bug hits, permissions are only partially assigned so as this happens again and again, a user’s consistency of access disappears. The only solution is to try and resynchronise the workspace with fingers crossed that it succeeds without another SQL deadlock. But you’re completely out of luck when running a batch job that affects several workspaces such as number 3 above. The workspace it reached before everything went horribly wrong doesn’t appear to be logged!

Because of the SQL deadlock failures, the SynchronizeMembershipForPwaAppRootSite() method in the WssInterop web service has been looked at. This performs a complete resynchronisation across all workspaces, functionality that is not available through the UI. Unfortunately with testing in UAT (less powerful than production but still a three server farm), this operation was going to run for days. Also, no other sync jobs could occur at the same time or else it would be SQL deadlock again!

Bugs are the worst, but implementation is also a shocker because of the huge length of time these jobs take to run. For example, up to 7 minutes for numbers 1 or 2 above, and 15-45 minutes for number 3 depending on number of users with changed permissions. This is exacerbated as more workspaces are created (the problem seems to be more related to number of workspaces rather than number of users). The server environment where this issue is occurring is very powerful and speed should not be an issue.

We’ve seen from Part 1 the deficiencies in design of this feature, but now also it’s implementation. So things can only get better in Part 3, coming next!

Project Server has its own SharePoint security groups which almost precisely equate to the standard SharePoint groups of Read, Contribute, Design and Full Control. The TechNet article Coordinate Project Server and Windows SharePoint Services security is the official word for exactly how permissions are assigned. Essentially just as SharePoint has its own built-in list of groups for “Read”, “Contribute”, “Design” and “Full Control”, then Project Server comes to the party with “Readers (Microsoft Office Project Server)”, “Team members (Microsoft Office Project Server)”, “Project Managers (Microsoft Office Project Server)” and “Web Administrators (Microsoft Office Project Server)”… blurrgh!

Here is a simplified summary of the rules that explain how users get their permissions. This is without the “(Microsoft Office Project Server)” suffix but with standard SharePoint group names in brackets:

• User that publishes the project has Project Manager (Design) permissions
• Users assigned to tasks within the project have Team Member (Contribute) permissions
• Users on the Resource Sheet of a project have Reader (Read) permissions
• Users that have Manage Windows SharePoint Services permission have Web Administrator (Full Control) permission over all workspaces
• Users that have Save Project permission have Project Manager (Design) permission over all workspaces

This looks complicated and it is. Try explaining to a project manager that access to documents in their workspace depends on who is added to the project’s Resource Sheet. It just doesn’t make sense! Then try explaining to an administrator why there is a group called “Readers (Microsoft Office Project Server)” as well as the standard SharePoint group called “Read”. It just doesn’t make sense!!

Then there’s the inflexibility of the rules themselves. There are no options – they are either on or off. And if you don’t go with MS on this one folks and uncheck the box for Workspace Permissions in Server Settings / Project Workspace Provisioning Settings, then only the Project Server service account is given access to new workspaces! This is hardly useful to the humble user needing to assign permissions who will never get their hands on this particular username and password. It just doesn’t make sense!

Don’t worry, there are solutions. However, they don’t come until Part 3! Next we look at how Microsoft’s solution is also slow, and even worse, buggy.

The following code retrieves the name of the SSP for the current site collection.

SPSite site = SPContext.Current.Site;
ServerContext serverContext = ServerContext.GetContext(site);

PropertyInfo srpProp = serverContext.GetType().GetProperty(
	"SharedResourceProvider",
	BindingFlags.NonPublic | BindingFlags.Instance);
object sharedResourceProvider = srpProp.GetValue(serverContext, null);
PropertyInfo srpName = sharedResourceProvider.GetType().GetProperty(
	"Name",
	BindingFlags.Public | BindingFlags.Instance);

string sspName = (string)srpName.GetValue(sharedResourceProvider, null);

From there the URL to the PSI web services within the SSP directly becomes the following (and the port number is always the following on every server):
http://servername:56737/SSPName/PSI/ or

https://servername:56738/SSPName/PSI/

This does seem overly complex so if someone out there has a better solution please add it as a comment to this blog or update the answer on Stack Overflow.

One way to try and access the administration page again might have been to stop or restart the queue service or the entire server itself, but what if unpredictable behaviour had disrupted those jobs? Instead, by carefully looking at the Project Server databases we can see the draft project database stores a lot of information about the queue in tables and views starting with MSP_QUEUE.

The following query gives a summary of jobs in the queue:

SELECT
  QPG.GRP_QUEUE_ID,
  QPG.CREATED_DATE,
  QPG.READY_FOR_PROCESSING_DATE,
  QPM.MSG_QUEUE_BODY_TYPE,
  QPG.GRP_QUEUE_MESSAGE_TYPE,
  QPG.GRP_QUEUE_STATE,
  QPG.PROCESSING_DATE,
  QPG.PERCENT_COMPLETE,
  QPG.COMPLETED_DATE,
  QPG.GRP_QUEUE_ERROR_INFO,
  QPG.GRP_QUEUE_PRIORITY,
  QPG.LAST_MSG_ID,
  QPG.LAST_ADMIN_ACTION
FROM dbo.MSP_QUEUE_PROJECT_GROUP_FULL_VIEW QPG (NOLOCK)
INNER JOIN dbo.MSP_QUEUE_PROJECT_MESSAGE QPM (NOLOCK)
  ON QPM.GRP_UID = QPG.GRP_UID
ORDER BY GRP_QUEUE_STATE DESC, GRP_QUEUE_PRIORITY, QPG.GRP_QUEUE_ID

This query gives how many jobs are remaining to run:

SELECT COUNT(*)
FROM dbo.MSP_QUEUE_PROJECT_GROUP_FULL_VIEW QPG (NOLOCK)
WHERE QPG.PROCESSING_DATE IS NULL

This query gives how many jobs of each priority are remaining to run:

SELECT QPG.GRP_QUEUE_PRIORITY, COUNT(*) AS [COUNT]
FROM dbo.MSP_QUEUE_PROJECT_GROUP_FULL_VIEW QPG (NOLOCK)
WHERE QPG.PROCESSING_DATE IS NULL
GROUP BY QPG.GRP_QUEUE_PRIORITY

There are also an interesting statistics table, although I haven’t yet found how to get a text value for GRP_QUEUE_MESSAGE_TYPE:

SELECT QPS.*
FROM dbo.MSP_QUEUE_PROJECT_STATS QPS (NOLOCK)

Ideally you would never want to execute raw SQL statements against the database, but as with any computer system, unpredictable things can happen. These queries might help with some troubleshooting.

Every project workspace out of the box comes with the Project Documents, Risks and Issues lists. On the add and edit pages of these lists, you can find “Link Items”:

Clicking Link Items while creating or editing an issue, for example, allows the issue to be linked to any task in the project. Also, this linking can have several meanings, such as whether the issue simply relates to the task, affects the task, or whether the task resolves the issue. Here is the dialog:

You’ll notice the drop-down at the top that reads Project Tasks. This can be changed so that this issue is linked to any risk, document or other issue as well! (Note there is no additional ‘meaning’ unless linking to a task.)

Upon clicking OK on this dialog box, a nice little summary is displayed of the link options chosen:

Of course, the issues list is just an example here. It is also possible to link items from the other lists previously mentioned. Here are the other dialog boxes shown…

Risk:

Document:

Linking’s cool, but now what?

Obviously whenever you look at a linked object you will be able to see and click on what each object is linked to which helps to describe the relations within your project, not to mention handy as well. Some examples are linking a document to a task for its delivery, or linking a risk item to a risky task! Also very useful is that the link gets propagated to the reporting database when the workspace’s project is next published, so some neat queries can be written to relate your data together.

What’s even better is what you don’t see. This functionality is powered by the Object Link Provider, which is described in some detail within the Project 2007 SDK. With some custom development work, it is possible to link tasks or project workspace items in other lists to any object you can reach with a URL. Imagine the possibilities – linking to an item in the company’s financial system, for example! This can all be done with the ObjectLinkProvider web service (examine the SDK for more details).

A few cautionary words

As you may have already encountered, some functionality in Project Server can break when you start altering project workspaces. This is even though it does nothing to stop you and virtually every customer/user has a requirement to. The Link Items feature is no exception here. If you delete the Links column from a workspace, there is no way I’ve found to put it back (this is probably because it is not a built-in SharePoint field type). Instead, try setting it to Hidden within the content type! In fact, hiding the field in the list’s content type should be done for every workspace field you don’t want to use.

Thanks for reading

Hopefully this provides a deeper look at a feature that doesn’t seem to get mentioned much. If you have good uses for “Link Items”, please add a few comments to this post!

First I must admit I’m not running the update as the service account, recommended by Microsoft. This is because I’m working in a locked down environment where trying to get the permission to do this requires a lot of questions, moaning and red tape. However both my account and the service account (there’s only one service account in use here) are local administrators.

The log file pointed to by the SharePoint Configuration Wizard contains this ever so helpful line: “An exception of type Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException was thrown. Additional exception information: Failed to upgrade SharePoint Products and Technologies.” However, with a little more digging there are details located at C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS. (This isn’t actually the folder where I have directed diagnostic logs to, but for the purposes of an upgrade it seems SharePoint sometimes redirects it!) The logs contain errors over the several times I tried to upgrade…

Upgrade.log:

• SqlException: The default schema does not exist.
• SqlException: Cannot find the object ‘MFN_Epm_GetAllCustomFieldsInformation’, because it does not exist or you do not have permission.
• SqlException: Cannot drop the function ‘dbo.MFN_Epm_GetAllCustomFieldsInformation’, because it does not exist or you do not have permission.

Then in the ULS logs:

• The schema version (3.1.4.0) of the database SharePoint_AdminContent on server_x is not consistent with the expected database schema version (3.1.5.0) on server_x. Connections to this database from this server have been blocked to avoid data loss. Upgrade the web front end or the content database to ensure that these versions match.
• SqlException: Cannot find the user ‘DOMAIN\myusername’, because it does not exist or you do not have permission.
• Queue unable to interact with SQL. Queue type (Project Queue, Timesheet Queue etc): ProjectQ Exception: Microsoft.Office.Project.Server.BusinessLayer.Queue.QueueSqlException: PeriodicTasks failed —> System.Data.SqlClient.SqlException: Invalid object name ‘MSP_QUEUE_RENDEZVOUS’.

It appears that I don’t have permission to the databases. However, my account is db_owner on every database The service account permissions haven’t been changed. What’s going on?!! It turns out the root of the cause was described this exception: The default schema does not exist.

I don’t know a great deal about the schema feature introduced with SQL 2005, however with every user added to a SQL 2005 box, an accompanying schema with the same name is also created. A colleague of mine who was doing some spring cleaning on our databases removed the schema for our service account, however the service account’s SQL user was still trying to use it as its default schema! The solution was to change the schema to dbo.

Unfortunately the upgrade still didn’t quite complete since I was part of the way through the upgrade when it fell over… I also had to create a fake MFN_Epm_GetAllCustomFieldsInformation function in the Reporting database so the upgrade could find and drop it (fortunately replaced with the new version in the upgrade).

It was a big relief that this ended up working. The downside is that my user account and a schema for it have been created on the database server. It can’t be removed right now because the new database objects that come with the update have my schema set as their owner! Now I have to change them all…

With the 2007 version, Project Server is now a SharePoint application. One of the best things about this is the nifty stuff you get out of the box as part of SP. Custom controls are a highlight, of which there are many that can be used in your custom Project Server solutions. Even better is that Project Server 2007 comes with some cool controls of its own which you can use in any solution running within Project Server. My latest discovery is the handy ItemSwapper.

ItemSwapper

This might look familiar to you from popular administration pages such as “Manage Queue” or “Manage Groups”. Just by popping one of these on your page, you get a pretty flawless interface to selecting projects. It’s also speedy and has some great features both client and server side. It’s great to use in a web part used for selecting report parameters, so that’s what we’re going to build in this post!

First of all, let’s have a look at two other custom controls used by ItemSwapper. There is the ItemSwapperLabel (extended from System.Web.UI.WebControls.Label) which renders the text above each list, and ItemSwapperSelect (extended from System.Web.UI.HtmlControls.HtmlSelect) which renders the list itself. Data binding is done with ItemSwapperSelect and the ‘parent’ ItemSwapper control renders all of these controls for you.

The ItemSwapper control refers to the two select lists as the ‘alpha’ and ‘beta’ lists (originally designed for Greek Project Server?). In our example the beta list will be blank for us to add projects into, so we only want to initalise the alpha list. Looking at the code, our CreateChildControls method contains:

protected override void CreateChildControls()
{
    alphaSelect = new ItemSwapperSelect();
    alphaSelect.Multiple = true;

    projectSwapper = new ItemSwapper();
    projectSwapper.ID = "projectSwapper";
    projectSwapper.TrackBetaListChanges = true;
    projectSwapper.AlphaSelect = alphaSelect;
    projectSwapper.LblAlphaList.Text = "Available Projects";
    projectSwapper.LblBetaList.Text = "Selected Projects";
    projectSwapper.DisplaySelectedItemText = false;
    projectSwapper.ShowBetaUpDownButtons = true;
    projectSwapper.ShowRestoreAllButton = true;
    projectSwapper.ShowRemoveAllButton = true;
    this.Controls.Add(projectSwapper);
}

This should be pretty self-explanatory (we will discuss the ID and TrackBetaListChanges properties later in this post). Now let’s perform a data bind in our OnLoad method:

protected override void OnLoad(EventArgs e)
{
    if (!Page.IsPostBack)
    {
        DataTable projects = DataLayer.GetProjects();
        projectSwapper.DataSource = projects;
        projectSwapper.DataTextField = "Name";
        projectSwapper.DataValueField = "Uid";
    }
}

This will now render fine, but the finishing touch is a workaround to what I would call a bug. If you set ShowRestoreAllButton to true, this will display the “Add All” button. However it is important to know that this button is greyed out unless the user has selected an item first, meaning that will need two clicks to add all projects to the other list. I don’t know why Microsoft would have done this, but to get around it, add the following code to our OnPreRender method:

protected override void OnPreRender(EventArgs e)
{
    alphaSelect.SelectedIndex = 0;
}

Have a look at the work so far as the ItemSwapper should now render!

Now let’s make use of the items chosen in the lists. First of all we’ll need a button in our web part for users to click on and start the report generation. We’ll also need at least one hidden field that will contain the selected items for us to use on the server side. Note that there is quite a bit of data we can get from the ItemSwapper JavaScript object, such as a count of items for both lists, text labels of chosen items for both lists, and values (e.g. project GUIDs) of chosen items for both lists!

To be able to do retrieve the data on the client side there are two key properties we need to set when creating the ItemSwapper which I touched upon earlier: ID and TrackBetaListChanges (or if you care about the alpha list, TrackAlphaListChanges). We need to use JavaScript to get a reference to the ItemSwapper object and setting ID lets us use document.getElementByID() to do this. (Surprisingly and fortunately, ID doesn’t get mangled in usual SharePoint fashion when rendered.) Setting TrackBetaListChanges sets a property on the JavaScript object to, well, track beta list changes.

So going back to CreateChildControls(), let’s add the following code and connect our server code to the client:

chosenProjectValues = new HiddenField();
this.Controls.Add(chosenProjectValues);

createButton = new Button();
createButton.Text = "Create";
createButton.Click += CreateButton_Click;  // server-side processing done in this method
createButton.OnClientClick = String.Format("SaveItemSwapperValues('{0}', '{1}');", projectSwapper.ID, chosenProjectValues.ClientID);
this.Controls.Add(createButton);

Everything’s ready now on the server side. We just need to create the SaveItemSwapperValues JavaScript function. Put this JavaScript wherever is standard for your projects.

function SaveItemSwapperValues(itemSwapperClientID, chosenValuesClientID)
{
    var chosenValuesField = document.getElementById(chosenValuesClientID);
    var itemSwapper = document.getElementById(itemSwapperClientID);
    chosenValuesField.value = itemSwapper.GetBetaListValuesAsString();
}

That’s it! Now when your server-code hits CreateButton_Click(), you should find a nice comma-separated list of project GUIDs in the Value property of your hidden field that can be used to generate reports!

But it’s nice to take things a bit further… Our Create button is always active, even when no projects are in the chosen list. Well then, behold! The ItemSwapper contains JavaScript event handling functionality! Add script that runs on startup such as this:

var itemSwapper = document.getElementById('projectSwapper'); // 'projectSwapper' should be passed as a parameter and not hard-coded
itemSwapper.OnAlphaListChange = ChosenProjectsChanged;
itemSwapper.OnBetaListChange = ChosenProjectsChanged;

Then add the following with the SaveItemSwapperValues function:

function ChosenProjectsChanged()
{
    var itemSwapper = document.getElementById('projectSwapper');
    var createButton = /* how you get this reference depends on your environment */
    if (itemSwapper.betaListItemCount == 0)
    {
        createButton.disabled = true;
    }
    else
    {
        createButton.disabled = false;
    }
}

Now we’re talkin’ – a smart ItemSwapper. And that’s not all, there is heaps of handy JavaScript goodness you can hook on to if you’re able to navigate to this file and have a look: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\PWA\LIBRARY\ItemSwapper.htc.

Last but not least, none of the ItemSwapper controls are sealed so you are free to extend them with your own functionality!