SPItemEventArgs::BeforeProperties and AfterProperties

Some useful posts (and its comments also!):

• http://www.sharepoint-tips.com/2006/08/bad-news-synchronous-list-events-bug.html
• http://msdn2.microsoft.com/en-us/library/aa979520.aspx

Summary:

• ChangedProperties always contains nothing
• Other members no always contain meaningful values – depends on event
• AfterProperties.Count will always be 0 but AfterProperties[COLUMN_NAME] will have values.
• The values stored in the AfterPropereties collection are all stored as strings

Excerpts:

I managed to also get information about the item in the ItemAdding event by using…
properties.AfterProperties["InternalColumnName"].ToString()
Note that the if the column display name has spaces in it (e.g. “Internal Column Name”) then the internal column name will most likely be something like “Internal_x0020_Column_x0020_Name”. User can change this collection item to change the value to be saved to database.
In the ItemUpdating event
properties.AfterProperties["Description"] will give the new value
and customer["Description"] will give the existing database value.
In ItemUpdated you can not get this as the valued have been commited.

Publish a Major Version – events

Publish a Major Version: this menu is only available when file is in a checked-in status. If it’s already checked out, it can only be checked in. When action is taken, ItemCheckedIn event is not called. Instead, ItemUpdated is called. However, both BeforeProperties.ChangedProperties and AfterProperties.ChangedProperties contains zero information so you can’t tell from ItemUpdated event if this is a “publish” action.

The version # will be automatically bumped to next major version #.

Unpublish this version: same as above, it’s also only available for checked-in status. The version # will be rolled back and ItemUpdated event will be called. ItemCheckedIn is not called (obviously).

If one want to handle these 2 menu actions, seems ItemUpdated event is the only entrance. However many other actions will also trigger ItemUpdated event.

If you want to remove these 2 menus,  edit core.js under \12\TEMPLATE\LAYOUTS\1033\ folder.  I commented out a section in AddCheckinCheckoutMenuItem function to hide the Unpublish menu. I did that because for unknown reason it would cause “Access Denied” error when someone does that after we customized the security.

Events in Microsoft Sharepoint 2007

MS provides very limited documentation on the sequence of the events, or what event(s) a particular action will incur. Here is my findings:

I didn’t handle xxxING events. Here are all xxxED events:

Folder operations:

• Add a folder: ItemAdded. No ItemUpdated.
• Delete a folder: very strange, ItemDeleted is not called. ItemDeleting is called. If folder contains files, files do not fire events. Update:ItemDeleted may have been called. But since the GUID is no longer valid so there is little use to catch this event.
• Update: If folder name is actually changed, both ItemFileMoved and ItemUpdated will be called. Otherwise, only ItemUpdated will be called. Note: even there are files under this folder, only one ItemFileMoved event will be fired for the folder.
• Restore from recycle bin: Note: neither folder nor the files within it fires ItemAdded or ItemUpdated event.

File operatins:

• Add file: ItemAdded. ItemUpdated and ItemCheckedIn will follow if choose to Checkin at the second step. When upload multiple documents, only ItemAdded will be called because there is no 2nd step window at all.
  When you add a new item, only the ItemAdding event is raised. However, in cases where Explorer View is used, both the ItemAdding and ItemUpdating events are raised. In such cases the ItemUpdating event always occurs after the ItemAdding event occurs.
• Checkin: ItemCheckedIn and ItemUpdated. There is no fixed order which one is called first. They are simultaneous.
• Update: If file is not changed, only ItemUpdated. Otherwise, ItemFileMoved will also be called. No fixed order.
  • Special note on file name change (same to folder name change): in one case, the ItemUpdated event handler throw exception in the middle due to a ‘File not found’ error. Please look out for this scenario.
  • Be careful when making changes in this event, which will incur next ItemUpdated event, which will also incur next. Put some logic there before making changes.
  • If the file is renamed in ‘Explorer view’ like a regular Windows file, only ItemFileMoved event is fired.
• Delete: ItemDeleting. See note about folder delete above.
• Delete from recycle bin: no event caught.
• Restore from recycle bin: ItemAdded
• Checkout: ItemUpdated/ing is NOT called (ItemCheckedOut should also be called which I didn’t verify). Note: however the version number increases when checking out (can be found in properties), not until check in. I’m a little puzzle since if version # changes, ItemUpdated should be called.
• Discard checkout: ItemUpdated/ing is not called.

Good reference: http://blogs.msdn.com/brianwilson/default.aspx