Steve Chen [MSFT] Sr. Support Escalation Engineer

...about SharePoint mysteries and related

Alerts in SharePoint Part II (Troubleshooting MOSS/WSS)

Alerts in SharePoint Part II (Troubleshooting MOSS/WSS)

  • Comments 6
  • Likes

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:

image004_20100416-160446_634070055077436690_

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)

Comments
  • Can you please discuss multiple email notifivation alerts being sent out when using sub-folders. Instead of one to eavh of the four alerts set up, 16 are sent out.

  • Hi Steve,

    I have an issue with my user alerts. We have created alerts for individuals in our organization. We have set the Event Type to New Items added. By default, Send Alerts for These Changes is set to Anything Changes. We only want users to receive a single alert when a new item is added. We do not want any subsequent emails sent when the item changes. I've tried everything for Send Alerts for These Changes and nothing seems to help. Any suggestions?

    Thanks!

  • HI Ann,

    I'm sorry but could you be a bit more specific with your alerts configuration and "folders" meaning? How did you enabled the alerts? on what event an alert should be fired?  what alerts are being sent "additionally"? what do you mean with 4x or 16x ?

    thnx and cheers, Steve

  • I have specific issue only with one content database , yes this is migrated contentdb & was working fine suddenly stopped sending emails. but it stores everything in sql tables.. only when i restart services in order tracing & then timer it sends emails which are stored! this works for another content database which is connected!

  • I had this issue recently and it appeared that the Immediate Alerts timer job for the web application that was not sending Search Alerts was stuck initializing.  I disabled the OWSTimer service on the server where the job was initializing and it aborted.  Then ran after 5 minutes from another server without issue.  It appears to be a configuration cache issue.  I think that the config cache became stale during the Immediate Alerts initialization and was stuck in that state.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment