Jean Barmash

When performing content ingestion, it is often needed to set some system properties that are governed by the Auditable Aspect. These properties are cm:created, cm:creator, cm:modified, cm:modifier. In 3.0 and 3.1, there is no explicit option to turn these off. If this issue affects you, please vote for this JIRA ticket, but in the meantime, here is a way to get around this when you need to disable automatic setting of these properties temporarily.

Note: we are using some trickery here, and doing things that aren’t typically recommended, so please be very careful and test things out in your environment. This worked for me on Alfresco 3.0SP1.

The auditing properties are being set pretty deep inside the infrastructure code (class HibernateNodeDaoServiceImpl). The code checks whether Auditable aspect is applied, and if so, it sets these properties explicitly. One way to disable this is by modifying the code. The way to do it more cleanly is by temporarily changing contentModel.xml. Auditable aspect applied is a mandatory aspect on cm:object, which is parent of cm:content.

Step 1 – Disabling Automatic Setting of Auditable Properties

So my solution is to remove Auditable as a mandatory aspect and to add those properties to cm:object directly. This is the new definition of cm:object.

<type name=”cm:cmobject”>

<title>Object</title>

<parent>sys:base</parent>

<properties>

<property name=”cm:name”>

<title>Name</title>

<type>d:text</type>

<mandatory enforced=”true”>true</mandatory>

<constraints>

<constraint ref=”cm:filename” />

</constraints>

</property>

<!–temporary added properties to go around auditable –>

<property name=”cm:created”>

<title>Created</title>

<type>d:datetime</type>

</property>

<property name=”cm:creator”>

<title>Creator</title>

<type>d:text</type>

</property>

<property name=”cm:modified”>

<title>Modified</title>

<type>d:datetime</type>

</property>

<property name=”cm:modifier”>

<title>Modifier</title>

<type>d:text</type>

</property>

<property name=”cm:accessed”>

<title>Accessed</title>

<type>d:datetime</type>

</property>

</properties>

<!—- Disable Auditable Aspect

<mandatory-aspects>

<aspect>cm:auditable</aspect>

</mandatory-aspects>

–>

</type>

Additionally, for convenience, it’s a good idea to not make these protected, or enforce them as being mandatory, as they are on the original Auditable aspect. As you can see, we commented out cm:auditable as mandatory aspect on this type, which means the code that sets these properties automatically will not get triggered.

Step 2 – Show Properties in the User Interface

The next step is cosmetic – we need to make these properties visible in our UI so it’s easier to test. For that, you will need to edit CONFIGROOT web-client-config-properties.xml. Add the auditable properties to “content” evaluator:

<config evaluator=”node-type” condition=”content”>

<property-sheet>

<show-property name=”creator” />

<show-property name=”created” />

<show-property name=”modifier” />

<show-property name=”modified” />

This will allow you to see these in the UI.

Step 3 – Set Properties, Migrate Content, Perform Bulk Load, etc.

After a server restart, you have now disabled the automatic setting of properties. You can either set them programmatically (and your changes will no longer get intercepted), or manually through the UI.

Note: This is an all or nothing operation – you can’t have it automatically set some properties but not others (to do it you’d have to do metadata extraction or some kind of event handler). This is why this is usually a temporary step as you are loading or migrating content.

After you are done with the content load, the next step is re-enable original model to ensure consistency. You also have a bunch of nodes that don’t have Auditable Aspect applied, so we need to reapply it.

Step 4 – Apply Auditable Aspect to Migrated Content

First, you need to revert to the original content model. To apply auditable aspect to many nodes, you typically write a JavaScript script that walks through the nodes and adds Auditable Aspect.

For applying Auditable aspect manually, you’ll have to add some code to CONFIGROOTweb-client-config.xml so it shows u in Add Aspect action.

<config evaluator=”string-compare” condition=”Action Wizards”>

…

<!– and the has-aspect condition –>

<aspects>
<aspect name=”generalclassifiable”/>

<aspect name=”complianceable”/>

<aspect name=”dublincore”/>

<aspect name=”auditable”/>

<aspect name=”effectivity”/>

<aspect name=”summarizable”/>

<aspect name=”versionable”/>

<aspect name=”templatable”/>

<aspect name=”emailed”/>

<aspect name=”emailserver:aliasable”/>

<aspect name=”taggable”/>

</aspects>

Another possible solution that might preclude this is to have a rule that automatically adds the Auditable aspect as you create nodes, but I haven’t tested that yet.

Step 5 – Restore original state of contentModel.xml and web-client-config-properties.xml

To get everything back to a consistent state, you now have to restore your original contentModel and UI properties. Because all nodes now have auditable aspect applied, as well as the properties that need to exist do in fact exist, Alfresco will now be able to pick it up from there and manage these properties the way it always does.

Tags: content modeling, migration

This entry was posted on Sunday, May 3rd, 2009 at 8:46 pm and is filed under Uncategorized, alfresco tech, dm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.