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.