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:

Unable to generate a temporary class (result=1).
error CS2001: Source file ‘C:\WINDOWS\TEMP\_zm3ve2y.0.cs’ could not be found
error CS2008: No inputs specified

Apparently, this is because the generated proxy class uses XmlSerializer somewhere internally. My guess is that it is de-serializing the soap messages into objects?

Some googling turned up the common answer of “just give the account access to the temp directory.” This seemed strange to me (also something our infrastructure team was wary of doing). Eventually I found this awesome answer by Richard. Essentially your options are:

1. Give the account access to the temp directory
2. Use the sgen tool to pre-generate the serialization assembly
3. Not use the proxy class (??)

In my opinion, using sgen is the logical choice. The documentation for sgen also puts it pretty clearly:

When the XML Serializer Generator is not used, a XmlSerializer generates serialization code and a serialization assembly for each type every time an application is run. To improve the performance of XML serialization startup, use the Sgen.exe tool to generate those assemblies the assemblies in advance. These assemblies can then be deployed with the application.

So all I needed to do was run this command against the Release version of my DLL:

This will generate another assembly: MyAssembly.XmlSerializers.dll. Cool!

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.

Support for rich text fields

This is an update to the SPNoteField class. In order to get this working, I had to do some funky stuff with internal SharePoint JavaScript functions: RTE_GetEditorIFrame, RTE_GetIFrameContents, and RTE_TransferTextAreaContentsToIFrame.

Support for unchecking multi-select checkboxes

I think this really was a bug, but I found that there was no way to uncheck one of the choices of a multi-select choice field. I updated the SetValue function to take an optional boolean second parameter. Passing it true will check the choice… false will uncheck.

Support for choice fields with fill-in values

I finally buckled down and implemented the code to support choice fields with fill-in values. Turns out this was a little more complicated than I first expected. I’m not sure how this will work with languages other than english because it seems difficult to find the “Specify your own value” radio button. It also complicates the SPChoiceField class quite a bit.

Either way, I tried to keep things as simple as possible and keep most of the burden in the library rather than on the developer/user:

1. Detects the presence of the fill-in textbox for every different type of choice field (radio, dropdown, multi-select)
2. SetValue is smart: if the value passed is a choice, then that choice is set. If not, then the fill-in value is set.
3. GetValue is also able to detect when the fill-in value is present

I’m hoping to break some of this logic down into smaller classes in the future but this will really all be cleanup work on my end. Which leads me into the next part…

Thoughts about future updates

My wishlist for future updates currently is:

1. Better documentation!
   I plan to start using PDoc (what Prototype.js uses for it’s API documentation)
2. To support #1, I’d like to break SPUtility.js into more manageable chunks and use Sprockets
3. To support #1 and #2, I’d like to start using github for the day to day version control. This is something I debated but I think I can use it for the full source and still use the codeplex site for the releases. I’m not sure where I’ll host the documentation yet.

Go download SPUtility.js at http://sputility.codeplex.com/. Feel free to post comments with feedback!

You can commit here: SharePoint Overflow.

From the changelog, here are some of the updates with more detail:

1. Bug: SPNumberField GetValue() function now disregards commas
   If the field contained a value like “1,000″ the value wouldn’t return as a number correctly. GetValue will now automatically convert the value from a string type into a number (ignores other characters).
2. Breaking change: GetSPFields will now return a hashtable instead of the array (see next item)
3. GetSPField now loads fields into a hashtable instead of an array (dramatically increases speed for forms with a large number of fields)
   This is related to how SPUtility stores the fields internally. Instead of using an array, it now uses a hashtable which will significantly speed up GetSPField calls… especially if you have a lot of fields in a list!
4. GetSPFieldType now attempts to prevent throwing an error when unable to get the field’s type (allows for easier Firebugging).
   This was more of an annoyance than anything.. made it harder to trap errors in Firebug because this method was throwing an error if it couldn’t parse the type.
5. New MakeEditable function, will undo MakeReadOnly
   Very useful if you want to only allow a field to be edited in certain circumstances.
6. Support for currency fields. MakeReadOnly will display the value with dollar sign, and commas. Uses formatMoney function made by Jonas Raoni Soares Silva.
   This leverages a new SPCurrencyField class. Like SPNumberField, GetValue now returns a number. I also developed a Format method but I’m not sure if this is something I want to include in the scope of SPUtility.js. Basically this function enforces a pretty field value… for example: $1,250.95 intead of 1250.95.
7. Support for single select lookup fields
   Lookup fields are strange because the field seems to switch modes depending on the number of items in the lookup list. For less than twenty items, a dropdown is used. For twenty or more, an autocomplete is used. It should work for both but I still have more work to do on these in order to make this class bulletproof.
8. Reformatted code to meet higher JSLint standards
   Mostly just whitespace and parentheses but I also refactored functions to have only one var. This helped because I was using var inside a couple loops.

Lots of good stuff in this release!

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:

First some fixes:

• If a field is read only, the label doesn’t automatically update.
  Update will allows developer to call MakeReadOnly again to update the label. I’ve been thinking about trying to make the label update automatically when the field value is changed programmatically, but calling MakeReadOnly again should work for now.
• New separate number field class that will always return a number (fixes issue with returning strings from a number field).

I’ll be including some new features as well:

• Support for Yes/No fields. New SPBooleanField class for allows for getting and setting yes/no fields. SetValue takes true or false and GetValue will return true/false.

Some TODOs:

• Support for Rich Text Fields
• Support for lookup fields
• Getting a SPField by internal column name

I also need to update the SPUtility.js documentation to include information about some properties that I’ve found to be very useful. I wasn’t sure entirely sure at first if they would come in handy. What am I talking about? Let’s say we have a requirement from our user to populate a Date field with today’s date IF they choose a Status of “Requested” from the Status single select dropdown. This is easy with SPUtility.js!

Using the SPChoiceField.Dropdown property, we can get the control and observe the onChange event.

I hope to get these features documented with the 0.4 release! As always, any feedback is appreciated; leave me a comment or contact me via Codeplex.

Let’s use the same example, but this time take advantage of SPUtility.js (the open source JavaScript library I maintain).

Our page’s URL would be something like:

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

I want to take the ‘projectID’ URL parameter and autopopulate my Project ID field with this value. Then, we’ll make the field read only.

We’ll dive right into the code:

To install, you’d simply place the JavaScript above into a Content Editor Web Part on your NewForm.aspx or EditForm.aspx. Take a look at the SPUtility.js Installation page for detailed instructions.

The first answer made me realize that undefined is not a keyword in JavaScript; it actually is a type that also happens to have a global variable with the same name. This means that you can change the value of undefined (the global variable) to be something else.

And, like shown above, the correct way to check if a variable is undefined is by using typeof.

The second feature, is something that I often used but had no idea why it actually worked: void(0).

According to Breton’s excellent explanation, void is actually a prefix operator. When you prefix any expression with void, the result evaluates to undefined. So, using our correct method for checking undefined above you get this in the console:

Awesome!