I am always looking for ways to make things work the way you REALLY want them to. Take the alerts in SharePoint as an example. Wouldn’t it be great to say “only alert me when this criteria is met”. Most of you are probably thinking that is as easy as a workflow, right? Well what if you really want to test the BEFORE and AFTER values of a field to make sure. Hmm…that might mean a custom workflow. New solution, look at the SPAlert object and look at SQL to see how this baby really works.
You ever looked at what happens after you go to a list and sign up to receive something that you didn’t change? If you see the CAML query that SharePoint generates, you might be asking yourself “what is this?”. The FieldRef points to a “Editor/New” column. What the heck? That doesn’t exist anywhere. Then again, Editor does, but what is this “New” thing? Look at some other types and you will see the “Editor/Old” popping up. Getting where I am headed? You know the SPAlert.Filter property has a get; and a set;, right? Hmmmmm…let your imagination do the rest. Create the SPAlert manually, or script it…you will like it.
$alert = $web.AllUsers["domain\kirkhofer"].Alerts.Add(); $alert.Filter = "<Query><Neq><FieldRef Name="_Status/Old"/><FieldRef Name="_Status/New"/></Neq></Query>"; $alert.List = $list; $alert.AlertType = [Microsoft.SharePoint.SPAlertType]::List; $alert.Title = "Status Change"; $alert.EventType = [Microsoft.SharePoint.SPEventType]::Modify; $alert.AlertFrequency = [Microsoft.SharePoint.SPAlertFrequency]::Immediate; $alert.Update($false);