So you disable the workspace permissions sync in PWA:

1. Navigate to PWA
2. Click Server Settings
3. Click Project Workspace Provisioning Settings
4. Validate that the “Workspace Permissions” checkbox is unchecked

Then, perhaps you write some code that is wrapped up in a nice SharePoint feature to manage setting up the permissions yourself. Everything works great….

… until you start getting reports that some user’s permissions aren’t quite right for some project sites.

You investigate and find a whole bunch of permissions with Project Server roles:

• Readers (Microsoft Office Project Server)
• Team members (Microsoft Office Project Server)
• Project Managers (Microsoft Office Project Server)
• Web Administrators (Microsoft Office Project Server)

More investigation into the PWA Manage Queue Jobs page, you also see “WSS Workspace Create” coming up in the queue.

Wait… I thought we disabled the permissions sync! Why is it still syncing from MSP?

If you’ve read this far, I’m guessing you’ve also written some custom code for Project Server using the Project Server Interface (PSI) (or you’re using the ProjTool app to publish the project). Which means, you’re probably using the Project.QueuePublish method and you probably have something like this:

When fullPublish is true, it will also sync permissions from MSP even when it is disabled in workspace provisioning settings. If the project site exists already, it will also sync permissions to that existing site.

The workaround is simple.. set fullPublish to false:

TODO: What is the difference when fullPublish is true vs false?

P.S. If you are managing your own security, I recommend using the SharePoint API to create workspaces instead of PSI methods. After you create the workspace from your project template, you can just link it up to the Project in MSP:

The XML from the Permissions GetPermissionCollection web service looks something like:

The main heartache I had when trying to use XPATH was that the XML uses a default namespace (the xmlns=”" part). In order to select the Permission nodes, you need to use a XmlNamespaceManager:

Here is another example on Stackoverflow.

As soon as another webpart was added, the entire page switched into some sort of weird publishing mode.

This new mode has a couple of changes to the form:

1. A publishing toolbar now appears at the top
2. Every field in the List View Web Part has an additional “form” label
3. Additional JavaScript is added to the page that prompts the user to save whenever an attempts to navigate somewhere differently: To save your changes before continuing, click “OK”. To continue without saving changes, click “Cancel”.

In my case, this new mode definitely would not work for what I was trying to do. The labels increase the size of the form dramatically, the publishing toolbar makes it seem as if you are editing the page rather than a list item, and this new mode does NOT appear on NewForm.aspx which means the forms are dramatically inconsistent.

After googling, I found a couple of people who have had similar issues. The root cause seems to be the Office SharePoint Server Publishing site feature. Since disabling the feature on the site was not an option, I had to find another way. JavaScript and CSS was a viable option (since I’m customizing the form using these anyway) but I felt like I needed a more bullet proof method.

My method involves using SharePoint Designer to customize EditForm.aspx. (Updated January 13th, 2011 after ADE’s comment below. Thanks a lot!)

Step 1: Create a new custom EditForm.aspx by right clicking on EditForm.aspx, click “New From Existing Page”

Step 2: Add the SPNavigation line in right before PlaceHolder Main:

Step 3: Save your new CustomEdit.aspx into the same directory as EditForm.aspx

Step 4: Verify your list now is associated with your new CustomEdit.aspx by right clicking on the list in SharePoint Designer and clicking “Properties”.

Your new edit form should be listed under the Supporting Files tab for Edit item form:

What we needed to do was wrap the column header so that it fit more to the data in the grid.

The solution is relatively simple to implement; all you need is a Content Editor Webpart at the bottom of the page somewhere with the following JavaScript in it:

I also took this opportunity to improve a process I have to do all the time: what are the internal column names in a list? To get the list information, I built a simple AJAX app that consumes the Lists.asmx web service. Please keep in mind that this code will have be uploaded into SharePoint in order to work (a document library will work) and will not run from your desktop.

Step 0: HTML for user input and displaying results

Since I will be calling the GetList method on Lists.asmx, I will need two parameters from the user: Site URL and List Name. Site URL gives the web service context to a particular web and List Name should be a list within that web. I also specify a DIV which is where I will display the list’s information.

Now that we have our HTML form, we can work on the JavaScript code.

Step 1: Building a SOAP Message

To communicate with the web service, we need to use SOAP. Luckily, Glen has already created a very handy class for taking care of these operations. It is also reusable so it will come in handy for other web service calls. I tweaked his code a little bit and then put it into SoapUtils.js (also, please note this code depends on Prototype.JS):

This utility class handles a lot of the grunt work for creating the SOAP message. It makes it pretty easy to grab the input, build the message, and then send it to the server. Next, I need to give it the specifics it needs to build the actual message. This is all contained inside my Execute function:

The Execute method is then bound to the “Get Columns” button on page load:

Step 2: Parsing the Web Service’s XML response

At this point, we are ready to handle the response from the web service. Unfortunately, parsing XML using JavaScript was not exactly the easiest experience. I haven’t found an easy way to do it, so if you have any ideas, please let me know in the comments.

In any case, if an error occurs, I simply want to print the error message:

A success message is a lot more complicated since we want to extract information out of the returned XML. In fact, if you look at the entire response from the webservice after calling GetList, the returned result for a simple Images library is something like 1100 lines of XML. The majority of this is taken up by the full description of each column in the list. There is a LOT of junk that we are simply going to be skipping over. For sanity sake, I’m not going to post the entire response, but useful snippets of interest.

Overall, the response will look something like:

Notice, the List node contains a LOT of useful information. Once we have that node, we can display a lot of it using this function:

Also, since we are interested in the internal column names, we want information about each of the fields. All of the columns are listed inside the Fields node (see above). A lot of them have attributes similar to below:

So, for each of the Field nodes, we are interested in the StaticName and DisplayName attributes:

And finally, to bring it all together, we are calling these functions inside our success function:

All together now:

August 20, 2010 Update: The code below has moved to be part of a bigger library… check out SPUtility.js on CodePlex!

Original Post:
This post builds off of my previous post about making fields read only. In this case, I needed to autopopulate the NewForm.aspx with a value that gets passed to the form via URL parameters.

In this case, the URL that gets passed in is something like:

/Lists/ProjectTasks/NewForm.aspx?projectID=523

I wanted to take the ‘projectID’ URL parameter and autopopulate my Project ID field with this value.

Additionally, we will make this field Read Only so that they can’t change the value. Lastly, do this all without SharePoint designer or C# code.

Stick the following code in a Content Editor on your NewForm.aspx or EditForm.aspx. (Remember you can get to edit mode by appending ToolPaneView=2 on the end, like NewForm.aspx?ToolPaneView=2)

Depends on Prototype.js.

The way that I chose to implement editing in an SPGridView involved two classes:

• SimpleLogic – handles query and update operations
• SimpleSPGrid – handles all of the setup for the ObjectDataSource and the SPGridView

The main advantage for splitting the two classes is to separate all of the business logic into one class. Ideally, you should be able to completely change how the SimpleLogic class retrieves/updates data without changing the SimpleSPGrid code.

The Setup

In this example, our logic class is retrieving and updating data in a SharePoint list. My SharePoint list had three main columns: Title (text), Region (choice), and Total Sales (currency).

Now that I had some data to read from and write to, I was ready to create my logic class.

The SimpleLogic Class

The goal for the logic class was to expose all of the operations the gridview would need in order to read or update data:

1. public DataTable Select()
   How do I get the data?
2. public List<BoundField> GetColumns()
   How do I display the data?
3. public void Update(Dictionary<string, string> data)
   How do I update the data?

DISCLAIMER: When actually implementing the class above, you will probably need to add some sort of error handling. In order to provide a simpler example, the error handling has been omitted.

Once our logic class is functioning correctly, we can work on hooking it up to an SPGridView.

The SimpleSPGrid Class

The SimpleSPGrid class contains most of the guts that will probably be different to you. The first thing to notice is that it takes our SimpleLogic class as a parameter. This allows us to instantiate our logic class beforehand with any parameters that are needed, and then pass it into SimpleSPGrid to use.

Wrap up

Now that all the hard work is done, we are ready to use the classes inside our web part. Inside the CreateChildControls of your webpart you would have the following code ( even though we have an SPWeb here, it should NOT be disposed):

This will produce the following grid!

And clicking edit…

For example, after uploading “NewTxtFile.txt” into a document library inside one of my sites, the following Audit Entries showed up.

Notice the “Occurred” DateTime properties are the same as well the Event. Also, one is an Update for the List and one is an Update for the Document. Using this information, you can then simplify the duplicate Update events into one Create event!

Update 08/18/2010:

Looks like Thomas found an easier method for determing Create events! I did some more research after seeing his comment and found the following:

1. Creates:
   • Document Audit Entry: EventData is null
   • List Audit Entry: EventData contains document filename
2. Edits:
   • Document Audit Entry: EventData contains version information

Here are the two events generated during a Create:

Here is the event that was generated after an Edit:

Thanks Thomas!

In general…

1. Don’t update SharePoint objects on a GET request
2. Call SPUtility.ValidateFormDigest() before anything on a POST request

Here are the two links to read:

• What you need to know about AllowUnsafeUpdates (Part 1)
• What you need to know about AllowUnsafeUpdates (Part 2)

Steps to repro this issue:

1. Create a site column named “A,B-C/D” (single line of text or any other type)
2. Create a list named “Special Characters (Site)”
3. Add the Site Column “A,B-C/D” to your “Special Characters (Site)” list.
4. Create another list named “Special Characters (List)”
5. Create a column in “Special Characters (List)” named the same as your site column (“A,B-C/D”)

Results:

The internal column names are DIFFERENT.

… but only for some of the characters. Looks like the comma and the slash are different but not the dash.