Alerts in SharePoint Part II (Troubleshooting MOSS/WSS)

Related posts in this series:
Troubleshooting MOSS
Alerts in SharePoint (Troubleshooting MOSS/WSS)
Alerts in SharePoint Part II (Troubleshooting MOSS/WSS) – This post
Alerts in SharePoint 2010 (Troubleshooting)

I recently had a case with alerts and the
“Issue: Not getting Alerts on new uploaded items but getting it for creating a new document via the library menue”.

So lets have a look at the configuration for this case:

Note!
All functions are available out-of-the box, no custom code or non-default function is used!

Configuration/Repro:

– You have a document library with several added columns. One of the columns has a choice field for “yes/no” and has the name “Orga” for example.
– The “Orga” Column has set as default value “no” -all other options are as by default (not required)
– You have created a view (lets name it also Orga) on the library that filters only documents that have the column value “Orga = yes”
– You now cerate an immediate alert for only new documents added that matches the filter view for “Orga”
– You create a new document via the “new” menue in document library by setting in Office word the property “Orga = yes”
– You also “upload” a new document to the library and set the upcoming property dialog to “Orga = yes”

Results:

– Alerts for the action “new” are fired as expected.
– Alerts for the action “upload” are NOT fired even though they are new to the document library  and matching the filter as well

Cause:
This is “by design” and relies on the logic of how and when SharePoint processes a document/item as “new” while adding it to the library.

In the above case, we have the following condition:

• When you create a document with the “new button” in the library, you’ll first open office word and inside word you set the property for “Orga” to yes. So on “save to library the property value already exists inside the document and SharePoint recognizes the document by respecting the filter which creates an immediate alert.
• When you “upload” a document to the library from a file share for instance, the initial upload process already has been done in background but not with the “Orga-Property” set to “yes”. This is done by a second process while you get the Property dialog to type in the properties (regardless if required or just optional) and now you first set the “Orga = yes” property. From SharePoint perspective, this is not a new document anymore and will be seen as a “change/edited” document although the filter would match after upload (which you can verify by just checking the “view” on the library).

Resolution/Workaround:

Usually you wont get around that behavior as far as it is respected as a “change/edit” by SharePoint. In this case we fortunately could resolve it with this workaround:

– On the document library, set the default value of the column “Orga” to “yes” instead of “no”. This causes that on uploading a new document, the library property will be set temporarily to “yes” even though you currently has not set it because you’re still in the property dialog while the document is already uploaded in the background to the library.

SharePoint now respects the “temporarily Orga value = yes” as match to the filter and as “new” which now fires the alerts as expected!

Note!
Some similar behavior you can observe when you for example “change the original file name” while you uploading the document via the property dialog. This is the same cause as described above and you’ll see in your alerts maybe duplicate links like the screenshot below:

You’ll see that the uploaded document (TestDoc2_ChangeOnUpload__x.doc) will have two notifications:

1. from the initial upload (this is the link that SharePoint stores in the alert template from the original filename) 
   -> marked as “new”
2. from the “changed filename” while the property dialog (I change the name to “TestDoc_ChangeOnUpload.doc” by deleting the  “__x” ) 
   -> marked as “Edited”

Unfortunately SharePoint does not change the link as well to the new document name  and therefore this is also a by design behavior relying on the logic the alerts are processed and the templates are built on Event.

(see more on troubleshooting alerts on my previous post here:  Alerts in SharePoint – Troubleshooting MOSS/WSS)