Adding Auditing to the Documents module

Hi all,

Had a google and a search of the forums here and the support docs but haven’t found a solution yet. I’m trying to enable auditing on the Documents module so that a Workflow for document approval can be tracked, just having an issue viewing the change log within the Doc module

I’ve added a php file to the /custom/Extension/modules/Documents/Ext/Vardefs/ folder with the following:

	$dictionary['Document']['audited'] = true;

a Quick R&R then creates the Audit table, and checking the table it appears to be logging changes. Issue is that I cant get the ‘View Change Log’ menu item from the record edit/action menu, nor find any information on how to do so

Has anyone got any pointers on what needs to be changed to add this?


I don’t think you need to do that from the Vardefs, you should be able to tick a checkbox in Studio.

Anyway, let’s try accessing this by URL first.

Try this format:

Obviously, change to whatever is your domain.

You also need to put your Document’s id in place of my id. To get it, just open the Document in Detail view and grab the id from the end of the URL:

It’s possible that your = sign will show as a %3D, don’t let that confuse you:

If this works we can go about finding a way to get the button to show.

Thanks for the reply,

Did initially try without the additional Vardefs line and just enabling audit on a field within Studio but no luck, line needs to be in there before a R&R will create the audit table. Once created auditing works correctly; I can view the recorded changes in the db, and the link you’ve provided appears to work correctly for each document I enter/edit. I’m just not getting the ‘Change Log’ link from within the Detail view of any Document record unfortunately.

I left it out of my original post accidentally, but tested on the following setups:

  • SuiteCRM 7.10.7 (Ubuntu & Win10)
  • SuiteCRM 7.10.2 (Ubuntu)

Same in each case on both releases


I don’t know, but maybe this will take you somewhere

I wonder about that isAuditEnabled variable… it seems to be at the Bean level, not at the field level…

Ok, I think I made some progress…

The Quick Repair and Rebuild does the work of creating new audit tables - so maybe after using Studio you needed to do a QR&R and forgot to.

I also found the bean-level audit setting.

It’s in modules/Documents/vardefs.php, we would need a line with ‘audited’ => true at the main level, so the upgrade-safe way to put it there is to create


(create any missing directories along the way)

Put this content into that file:

$dictionary['Document']['audited'] = true;

Do a QR&R and now you can see a “View Change Log” button in the Edit view. It’s not showing in the Detail view, for some reason…

For the Detail view it seems to depend on these conditions

That’s what I did initially, just to check:

-> Studio -> Documents -> Fields -> [Selected Field] -> Audit Checked -> Save -> QRR

Always get the message ‘Documents not Audit Enabled’ and no table is created.

Appears the extra manual code is required as we’ve been doing. If I create a file auditEnabled.php with the ‘audited’ => true line then a QRR creates the _audit table and the logging functions fine.

I did a little more digging and some tests though; interestingly if I enable auditing on the Tasks or Calls modules with the above process, I do get the ‘View Change Log’ button in the detail view without any further tweaks, so it looks like this issue is limited to the Documents module in some way…

Created a PR with the changes required to enable the button:

Hm, a PR, nice!

(you’ll have to clean it up a bit, it’s including previous changes by other people)

What is your opinion, shouldn’t Documents have “audited” enabled by default? Any reason not to, if other modules do? People can still edit which fields they want to audit from Studio… but it would be nice to not force users to go into PHP files to enable this…

In that case we would simply add a line with ‘audited’ => true at the main level directly in modules/Documents/vardefs.php

Haha yeah, haven’t submitted changes on github before so the process was a little hit/miss. I’ll try tidy it up tonight - thanks for the earlier pointers down the right track

I can’t see a reason not-to, for our deployment I’ve been through all the other Modules we have available and enabled auditing where it wasn’t by default. Just for added clarity on changes / internal QC

Updated PR for future reference:

1 Like