The Audit logs are a great resource for identifying when certain changes were made and by who. The key difference between Audit Logs vs. Analytics actions is Audit Logs record Admin changes that are not otherwise recorded in Analytics.
Please note, not all actions taken by admins in the admin console will be logged in the audit log. Nor will the audit log record actions taken by end users.
The Audit Log viewer (Admin Console)
- Verified for version: 6, 7, 8, Cloud
Fast Track: Advanced Admin Console > System > Management > Audit Log Viewer
Let's start by breaking down the anatomy of the audit log viewer. We have the Filter Options, Page Controls, and Results:
Filter By User
Here we have three values that can be specified. These are the "Start Date", "End Date" and "Filter By User". The "Filter By User" field targets the user who was the actor for the action that was taken.
The user who is specified in this filter cannot be the person whom the action was made against. For example, if you wanted to know who changed a specific user's "Location" field via the admin console, Filter By User would not help you do this.
However, if you wanted to locate which users profile fields were changed by one of the admins, you could set this filter to target the admin user in question. The results would display each action taken by that user and when the action was taken.
Start and End Date
Many actions are recorded in the Audit Logs. So much, in fact, that it can be difficult to locate a specific action. The Start Date and End Date filters will significantly narrow the scope of the data so that it is easier to locate the desired changes.
Use Items per page to control how many results are shown per page. As a rule, it is often a good idea to set this to its max value if you are looking through a broad date range. Since there is no search functionality in this view, setting the value to it's max setting (50) will reduce the amount of scrolling through pages needed.
The exact timestamp (based on the system locale setting) when the action was made.
This is where you will spend most of your attention when reviewing the activity in the logs. This contains a description which references what was done by the admin user. In some cases, this is a straightforward description such as "Partial content search index rebuild initiated". In other cases, the Description references SQL, Java Classes, or other programmatic terminology that may not be as clear, e.g. "setTagsType called on DbTagManager". When this is the case, you can often find much more information in the Details by clicking "Click for Details". Let's take a look at the last example.
Click for details
The first line "protected void" refer to the Java Class that is connected to the action and, for the most part, won't be too useful in your search. In this example, the next line is the Java Class that was executed by the action. You can get clues about what is happening from these classes, even if you are not a Java developer. Jive often uses logical naming for these classes. For example, if a class is called "com.jivesoftware.community.impl.DbTagManager.setTagsType", this could indicate that the action had something to do with tagging content. One might ask at this point, am I here because I'm looking to know who or when some content was tagged? If so, you would continue to look for similar entries. Otherwise, you could safely assume this is not the action you are looking for and move on.
Apart from the Java code in these details, you may notice Object ID's and types being referenced in these details as well. These are how you will identify what object the action was taken against. Let's look at the earlier example again:
docID=1666, documentID='DOC-1666', containerType=2020, containerID=1078, versionID=1, documentState='published', userID=2085, creationDate=1471988781453, modificationDate=1471988781614, authorIDs=, versionAuthorIDs=null, reviewerIDs=null, commentStatus=2, workflowID=null, authorshipPolicy=2, currentUserID=-1, status=PUBLISHED, exStorageFileID=null, exStorageFileVersionID=null
We can see that the object that was targetted in this case was DOC-1666. We also see a container ID and container Type, the version and state of the document, when the document was created and modified, and so on. Though this information requires knowledge of the numerous enumerations Jive uses, Jive Support can use these details to locate objects in your instance. Providing these details in your support case is highly encouraged when possible.
The node is the Node IP address of where the action was taken. This will usually reflect an internal IP address that is behind a load balancer. Hosted and On-Premise installations can pair these IP's to the cluster member in Admin Console > System > Settings > Cluster. This will tell which node the user was on when they made the action.
The JiveAuditLog table (On-Premise Only)
Reminder: Jive Support does not assist with SQL queries. Community Managers should work with their DB admin for assistance searching through the JiveAuditLog table.
Since the UI in the Admin Console is lacking a Search feature at this time, Database Admins may want to use the power of SQL to search through the Audit Logs. The same logic that would apply to the UI can be structured into queries and ran against the App DB. DBA's should make use of the Jive 8 Schema for details on the table.
- auditmessageid = Primary Key and unique identifyier attached to each audit log entry
- userid = This is the same as the"Filter By User" field in the Admin Console. It is the user ID of the person who took action, not the person whom the action applied to.
- timestamp = The time the action was taken. Use this field with < and / or > operators to narrow the timeframe to achieve the same results as the "Start Date" and "End Date" in the Admin Console UI
- description = Same as the Description column in the Audit Log Viewer.
- node = Same functionality as the "Node" line in "Click fo details" view in the Audit Log Viewer.
- details = Same as the "Click for details" view in the Audit Log Viewer.