While experimenting with some permission settings on a SharePoint Survey List this evening I made a rather nasty discovery:  Page separators and Edit Access permissions do not mix:

Allow me to explain:  I have a SharePoint Survey List that has sets of questions that I aggregate together using the Page Separator field type – this keeps the survey UI manageable for the user it is a bit lengthy (forty-seven questions in a mix of multi-choice and free text fields).  Not a big deal – well within the realm of what an OOTB Survey List is designed to handle.

However, a recent requirement surfaced during an iteration planning session to control edit access to submitted surveys – once a response is submitted, a user shouldn’t be able to go back and change it.  Again, this shouldn’t be a problem, I thought – just modify the Edit Access permissions for the list from the Advanced Settings (see above picture) and set to None.

And so it began:  When I logged in to the list as a regular user and responded to the survey, everything was going well on the first page:

Then, I clicked Next…

NO ACCESS FOR YOU, ADINAA!

What’s the issue?

In a word:  Permissions.  In many more words, a combination of permissions and the lifecycle for a SharePoint Survey List Item.

When a user first clicks Respond to this survey on the list, SharePoint creates a row for the new response record and fires the ItemAdding and ItemAdded events.  When the user then clicks on the Next button to move things along past the page separator to the next series of questions, SharePoint updates the record and fires the ItemUpdated event.  The only way you know whether a survey respondent has actually completed the survey and clicked Finish is by checking the list’s Completed field for a value of “1” (it’s “255” otherwise) while you’re in the ItemUpdated event handler.

It’s this event that the aforementioned permissions are gated against – when the list Edit Access permissions are set to None, any attempt by a non-admin user to “update” their record by clicking Next is met with an Access Denied response.  Change the settings back to Only their own, and the expected functionality is restored.

What’s the workaround?

Um – haven’t thought of one yet as this is really tied to how the Survey List behaves at a functional level.  In my case, the quick and dirty solution may be satisfied by another user story which describes closing off access to a survey once the Survey Closed Date has passed.  Initially, this will involve removing Contribute permissions on the list for non-admin users and restricting them to Read Only – but this still doesn’t solve the problem of editing submitted surveys prior to the close off date.

I may have a solution shortly, but for now I am noting this as a “known issue”.

Earlier today, I was working on a custom survey list event receiver that ports results into a SQL database table when I noticed some peculiar behaviour:  Every time I added an entry to the survey, two duplicate rows were added to the SQL table.

Poking around the web, I see that this is indeed a common issue – David Birin captured the problem (and a solution) quite succintly on his blog in his January 2009 entry.  As he notes, the root of the problem is that if you have your event receiver deployed as a Feature (I did) and then create a template of a targeted list (you bet I did that) then the event receiver registrations are “baked in” to the template definition.

Now, when you create a list based on this template in a site that has the same event receiver Features enabled, you now are running each event handler twice.  As you repeat this process, you register more event receivers and things get out of hand geometrically.

NOT GOOD.

A Hack for a Solution

David’s solution is to add in some custom code that loops through the event receivers and deletes them individually.  While this is robust for future-proofing, I wanted an easier way so that I could get back to coding.  Here’s what I did:

1. First, I went to the List Template Gallery for my Site Collection and saved the offending list template to my C:\ drive and renamed the extension from “.stp” to “.cab”
2. Next, I opened up the .cab file and extracted the manifest.xml file within and tossed it into Visual Studio where I cleaned it up with an Edit -> Advanced -> Format Document
3. I located the <Receivers> element and removed each <Receiver> child element.
4. I changed the <TemplateTitle> to reflect the new version, eg. “My Survey V4”
5. I made similar changes to the <Form> and <WebPart> element URL attributes, eg. “Lists/My Survey V4/DispForm.aspx”
6. Next, I saved this file and then used MAKECAB.EXE to package it up (comes with the Windows SDK) and renamed the extension from “.cab” to “.stp”
7. I opened up a browser on my test server, navigated to the List Template Gallery and uploaded my revised template and created a list from it.
8. Presto!  The ItemAdded event was only firing once as it should.

Hope this helps anyone encountering the same issue – it’s a quick-fix which helps avoid the ground-zero for the issue which is building a template of a list while the event receiver feature that targets that list is enabled.

Via the Microsoft SharePoint Team Blog, SharePoint MVPs Andrew McConnell and Robert Bogue are presenting a 10–part series covering development fundamentals and best practices.  These began a couple of weeks ago (the recorded webcasts should be available soon) and the balance will be delivered via LiveMeeting over the month:

See the post for details and links – there’s also some upcoming P&P sessions for architects and if you happen to be in Redmond for June 11, a “SharePoint Fire Starter” 1–day whirlwind intro event.

So, you’re called in to a large organization that is wanting to do a consolidated MOSS rollout for an enterprise intranet.  You’ve been warned that due to some rather “relaxed” attitudes toward server deployments, there are a number of pre-existing WSS servers scattered throughout the enterprise that should be migrated toward the central platform.

You’ve got a day or so to pull an inventory together, and by the way: The guy who knew where all these servers are is currently vacationing in the Swiss Alps.  What do you do?  What do you do?

Download the SharePoint Asset Inventory Tool on a server that has wide-ranging visibility and permissions and let it do the work:

The SharePoint Asset Inventory Tool allows IT professionals to inventory all of the computers in the network and identify servers that have SharePoint installed on them. The information gathered by the tool is used to generate reports that give IT the information it needs to bring the servers under its control. This allows the resources of the ever-changing SharePoint environment to be optimized and adjusted as needed.

There are only three (3) things you need to have installed on the host server to make the magic happen:

1. SQL 2005
2. SQL Server Reporting Services
3. .NET Framework 2.0

Go forth, be inquisitive and crafty!

Via Bink.nu, news straight outta Redmond that the hitherto model for distributing WSS (ie. a separate, free download vs. OOTB bundle) is being revived.  The reason?

Starting with RC1 and going forward, Windows SharePoint Services 3.0 will have to be downloaded separately. Basically, we made this decision to allow customers to most conveniently obtain the technology while allowing Microsoft to have flexibility in the Windows SharePoint Services development process.

Oookaaaaaay.  I'm not sure how it's going to be more convenient for me to have to download the 70 MB+ install for WSS (excluding SPs, etc.) than have the core version installed by default or at least something that could be configured to install during setup - but that's just me.  Further, WSS was never integrated into the core for Windows Server 2003 - it always was a bolt-on that sat atop the .NET/ASP.NET framework - so, how is this impacting development again?

Maybe recent news on the Windows Server vs. Linux market share front is prompting this decision to encourage even greater penetration - but WSS seems like a no-brainer for the environments that Windows Server will be installed against, especially if you're giving it away and using it as a loss-leader to get MOSS 2007 in the back-door.