Second Life of a Hungarian SharePoint Geek

May 12, 2017

Disabling SharePoint Alerts Temporarily for a Specific SharePoint List

Filed under: Alerts, PowerShell, SP 2013 — Tags: , , — Peter Holpar @ 05:16

Recently we extended a SharePoint list in our test environment with a few new fields. Users have been complained that they received immediate notifications due to their existing subscriptions on the list. To avoid the same situation in the live system, we decided to temporarily deactivate the alerts for the time of the list field extension. I find a solution for that in this thread, implemented in C#. Although I like C#, for administrative tasks like this one I prefer using PowerShell, so I transformed the code into a few-line script:

$url = ‘http://YourSharePoint/WebSite’
$listTitle = ‘Title of your list’
$targetStatus = [Microsoft.SharePoint.SPAlertStatus]::Off # or [Microsoft.SharePoint.SPAlertStatus]::On

$web = Get-SPWeb $url
$list = $web.Lists[$listTitle]

# to query the current status of the alerts only:
# $web.Alerts | ? { $_.List.ID -eq $list.ID } | % { $_.Status }

$web.Alerts | ? { $_.List.ID -eq $list.ID } | % {
  $_.Status = $targetStatus

After implementing the changes, you can reactivate the alerts (in this case you should use the value [Microsoft.SharePoint.SPAlertStatus]::On in $targetStatus), however, you should wait a few minutes, as the immediate alerts are sent every 5 minutes by default (see screenshot below). If you turn the alerts on before the next run of the job, your previous change to inactivate the notifications has no effect and the alerts would be sent to the user.


By letting the Immediate Alerts job to have a run after you make the changes in the list, the notification events waiting in the event queue will be purged and not included in the upcoming immediate alerts. They will be however included in the daily and weekly summaries, but that was not an issue in our case.

If you don’t want to wait for the next scheduled run, you can start the job from the UI (see Run Now button above), or via script like this:

Get-SPTimerJob | ? { $_.Name -eq "job-immediate-alerts"} | % { Start-SPTimerJob $_ }


January 29, 2015

The Pitfall of SharePoint Alerts

Filed under: Alerts, Bugs, SP 2010 — Tags: , , — Peter Holpar @ 22:50

Recently we received a complain from one of our users. She has created a subscription for alerts on changes of a list, but as she decided later to cancel the subscription, she got an error (access denied). The problem was easy to reproduce, and the reason was pretty straightforward as well. Users who have permissions on a specific list, but not on the parent site of the list may be affected by this “design issue”. We faced the error on SP 2010, but as far as I see it affects MOSS 2007 (WSS 3.0) and SP 2013 users as well.


For those of you who would like to know the technical background of the issue: you can create the alert from the list ribbon via the application page SubNew.aspx, and manage them via the MySubs.aspx page, both of them are located in the _layouts folder. The code behind class for these pages are the SubNewPage and the MySubsPage classes respectively from the assembly Microsoft.SharePoint.ApplicationPages (and the same namespace). There is no security check in the OnLoad method of the SubNewPage class (nor in its base classes), however in the OnLoad method of the MySubsPage class the CheckRights method of the LayoutsPageBase class (Microsoft.SharePoint assembly, Microsoft.SharePoint.WebControls namespace ) is called. This method checks, if the current user has DefaultLayoutsRights permission (that means SPBasePermissions.EmptyMask | SPBasePermissions.ViewFormPages | SPBasePermissions.Open | SPBasePermissions.ViewPages) on the parent web, and not on the list. If not, the user is not able to manage the alerts she created earlier.

Blog at