This post provides information about the item level auditing and how the server side object model works.

When you create site collection the auditing is not enabled by default. Each content database has a AuditData table to store the auditing information. You can enable the auditing at the site collection level through Site Settings => Site Collection Audit Settings. You can view the Audit Logs through Site Settings –> Audit Log Reports.

When no auditing is enabled and if you try to see / generate any of the available audit reports you will end up with a screen which says “Something went wrong”.

Now let’s walk through 2 scenarios to get some understanding about the SharePoint 2013 Item level Auditing.

Scenario 1 – No Auditing

Now in a clean new environment we will check the Audit status of the SPSite, SPWeb, SPList, SPListItem.

In the example we have a site collection and it has a Document Library names “AuditDocLib” and it has one document.

   1: private static void PerformAuditFeatureCheck()

   2: {

   3:     string url = @"http://singlespserver/";

   4:  

   5:     using(SPSite site = new SPSite(url))

   6:     {

   7:         var siteAuditFlags = site.Audit.AuditFlags;

   8:     

   9:         var topLevel = site.OpenWeb();

  10:         var topLevelAuditFlags = topLevel.Audit.AuditFlags;

  11:         

  12:         var sharedDocLib = topLevel.Lists.TryGetList("AuditDocLib");

  13:         var shareDocLibAuditFlags = sharedDocLib.Audit.AuditFlags;

  14:  

  15:         var doc1 = sharedDocLib.Items.GetItemById(1);

  16:         var doc1AuditFlags = doc1.Audit.AuditFlags;        

  17:  

  18:        }

  19: }

When we run the above code AuditFlags of the SPSite, SPWeb, SPList and SPListItem is None.

Scenario 2 – Enabling Audit for specific ListItem

Now we’ll enable the auditing for a specific document in the AuditDocLib.

   1: private static void EnableAuditForItem()

   2: {

   3:     string url = @"http://singlespserver/";

   4:  

   5:     using(SPSite site = new SPSite(url))

   6:     {

   7:         var topLevel = site.OpenWeb();

   8:         

   9:         var sharedDocLib = topLevel.Lists.TryGetList("AuditDocLib");

  10:         

  11:         // AuditFlag is None

  12:         var shareDocLibAuditFlags = sharedDocLib.Audit.AuditFlags;

  13:  

  14:         var doc1 = sharedDocLib.Items.GetItemById(1);

  15:         

  16:         // AuditFlag is None

  17:         var doc1AuditFlags = doc1.Audit.AuditFlags;        

  18:  

  19:         //enabling auditing for the item

  20:         doc1.Audit.AuditFlags = SPAuditMaskType.View;

  21:         doc1.Audit.Update();

  22:     }

  23: }

Now doc1 is audit enabled. And in the Audit Log Reports we can get the Audits. Below image shows the screen shot of the audit report after viewing the doc1 for few times.

Notice that the report also has the log entries for the Library (AuditDocLib). It is obvious that if a person want to view an item in the library more often he/she has to navigate to the corresponding List/Library and view the Item. But we didn’t specify to audit the Library; in the code the AuditMask is set only for the item.

Again we’ll run the PerformAuditFeatureCheck method to check the AuditFlags

You can see that the AuditFlags for the AuditDocLib is still None. This is because AuditFlags were not set for the AuditDocLib explicitly beacuse there’s no <NewAuditMask>4</NewAuditMask> event against the AuditDocLib.

This also hints us a point that just by retrieving the AuditFlags of a List / Library through the object model doesn’t give you the full insight of whether the particular List / Library is being audited. AuditFlags property gives the value of the last explicitly set AuditMask.