The current implementation of auditing couples two concepts that, in my estimation, should not be coupled. In particular, the auditable aspect is used to set file modification dates and the user that did the modification. The result of this is that any tool that needs to, for some reason, set those properties must first disable the auditable aspect behavior, which not only allows those dates to be set but also disables auditing entirely - often an undesirable side-effect.
The bulk import tool (both the official Alfresco embedded version and the community version). In org.alfresco.repo.bulkimport.impl.MultiThreadedBulkFilesystemImporter, behaviors related to the auditable aspect are explicitly disabled (line 126) so the tool can preserve file creation / modification dates from the filesystem being imported.
The problem with this is that customers in environments covered by certain regulatory requirements need to be able to audit these activities, even as this logic forces specific values for creation / modification dates. As it stands today, customers with stringent audit requirements cannot use the Alfresco provided bulk import, as it can import and modify content without recording any audit entries whatsoever. A better approach would be to decouple the setting of the modification date and modifying user properties from the recording of audit entries, permitting extensions and Alfresco’s own code to set these modification related properties without requiring the audit behaviors to be disabled.
This is currently a blocking issue for a large OEM partner / premier customer.