Update Items Quietly

There may come a time where you’ll need to update many items in a list and doing it manually would take way to long. In this post, I’ll show you how to modify list items without changing the last modified metadata and without firing an alert.

In this example, I’m going to change a single item in the announcements list. Here’s my item before I edit it. I’ve highlighted the Title (which is what I’m going to change) and the last modified information.

Now, the code is simple. All I’m doing is getting the specific item by its ID and adding “(Changed)” to the end of the title. To make the change quietly, you can’t use the item.Update() method. Instead, you’ll use item.SystemUpdate(). SystemUpdate will make your changes without firing an alert or updating the last modified information.

After I run my code, you’ll see that in the result, my title is changed and the last modified information is still the same.

One last thing. SystemUpdate also takes a boolean parameter. By default, the value is false; however, if you set it to true, the version number of your item will increment. If you choose to make the change and increment the version number using SystemUpdate(true), the last modified information will still remain the same and you still will not trigger an alert.

When Webparts Go Bad

There will come a time when a webpart fails, your site is displaying an error, and you can’t do anything on the page.
You’ll want to remove the webpart that is causing the problem but if you look at the error page above, you don’t even have a Site Actions menu. To get around this, you have to add a query string. Go to your URL and append ‘?Contents=1′ to the end as in the next image.
Now, this will take you to the Web Part Page Maintenance page. As you can see, this page will list every webpart that is currently on the page. Select the webpart that you believe is causing the problem by clicking on the checkbox and click on the Delete button.
NOTE: The delete button simply removes the webpart from the current page, so you don’t have to worry about deleting the webpart from all existence.

Running with Elevated Privileges

There may come a time when you need to run some code on a site regardless of who’s logged in at the time. Before, you would have to impersonate an account that has the privileges needed to execute the specific line(s) of code. Now, there are 2 ways that you can run the code without having to do an impersonaation.
Method#1
Create an SPSecurity.CodeToRunElevated object. When instantiating this object, it expects you to pass a method name as a parameter. Follow this line of code with an SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated object).
In the image below, you’ll see that I create a CodeToRunElevated object called elevatedCreateWeb and I’m passing in the name of my method that needs elevated privileges (CreateWeb). The next line is passed the object that I just created.
This method is the cleanest (easiest to read) way to do this.
Method#2
This method is a little more difficult to read but still simple. Instead of creating the 2 lines as in the example above, you’ll just need to create the second line. Now, since you don’t have a CodeToRunElevated object, you need to pass in delegate() { full code here }.

When you add your code, it will look something like this next image.

If you’ve taken a real good look at the last bit of code, you’ll notice 2 using statements that are used to create an SPSite and SPWeb object. You’ll also notice that when I instantiate them, I’m using other SPSite and SPWeb objects. I’m doing this because you can’t use an SPContext inside the code being run with elevated privileges. If instead I write SPWeb site = SPContext.Current.Web, inside my using statement, you may see an Access is Denied error because your web was created in the context of the current user.