I have a requirement to show a history of changes to a certain property of site. This is for a custom node type (derived from 'st:site'.
I've read about the MetadataTracker in this interesting post by Andrea Gazzarini, which looks to be relevant
https://community.alfresco.com/community/ecm/blog/2019/04/10/the-alfresco-content-tracker
But I'm unsure how to use this, as there is no practical example of how to apply it.
All I want to do, is show the user the history of what changes were made to the property (and possibly who made them). If there is some out-of-the-box way of doing this, that would be ideal.
Otherwise, any guidance to resources which explain how to do this would be most appreciated.
Solved! Go to Solution.
The MetadataTracker is relevant ONLY for SOLR indexing, and NOT for maintaining a full history of changes.
What you are looking for is more in line with Behaviours / Policies. With these you can react to a multitude of events, e.g. OnPropertiesUpdate, and record the relevant information in any form of history / log you want. In Alfresco 6.1 there is even a way to use a messaging queue to process these events asynchronously and out-of-process, though there doesn't seem to be any documentation on how to use that yet, despite it being one of the key features in the latest release. The only mention I could find of it is from a DevCon 2019 talk on archtiectural changes (2-3 slides only).
Alternatively, there is Auditing, which is a meant to record arbitrary custom data originating from node changes and/or API invocations and allow for the recorded data entries to be queried / retrieved, but it can be quite complex. Also, it is expected that auditing will also shift more to an out-of-process approach at some point similar to the event-related queue. Additionally, unless you are already quite familiar with Auditing, it can be easy to fall into various performance / scalability traps due to naiive implementation approaches.
The MetadataTracker is relevant ONLY for SOLR indexing, and NOT for maintaining a full history of changes.
What you are looking for is more in line with Behaviours / Policies. With these you can react to a multitude of events, e.g. OnPropertiesUpdate, and record the relevant information in any form of history / log you want. In Alfresco 6.1 there is even a way to use a messaging queue to process these events asynchronously and out-of-process, though there doesn't seem to be any documentation on how to use that yet, despite it being one of the key features in the latest release. The only mention I could find of it is from a DevCon 2019 talk on archtiectural changes (2-3 slides only).
Alternatively, there is Auditing, which is a meant to record arbitrary custom data originating from node changes and/or API invocations and allow for the recorded data entries to be queried / retrieved, but it can be quite complex. Also, it is expected that auditing will also shift more to an out-of-process approach at some point similar to the event-related queue. Additionally, unless you are already quite familiar with Auditing, it can be easy to fall into various performance / scalability traps due to naiive implementation approaches.
Thanks Axel for your helpful response. Yes I'm familiar with attaching Behaviours to respond to document updates. That was the approach I had in mind, but was wondering if Alfresco provided some ready solution, in a similar way to the tracking of document content history/changes.
The Auditing strategy doesn't sound like a road we want to go down, as we do lack familiarity with that feature.
Hi Andrew Fielden, thanks for the referencing my post.
Just to add my 2 cents: I can confirm the current design of the tracking subsystem is not thought for fitting your needs.
It is an internal component of SearchServices (that's the reason why you don't find any practical example in my post), so that means it's valid only when you have Solr as part of your search infrastructure.
In addition, trackers don't provide any callback mechanism for sending notifications about events.
Although everything is possible, implementing such feature would require some custom code and a relevant change in an internal component. So briefly, that's not a ready solution: definitely better to go with the approach described by Axel Faust
Cheers,
Andrea
Ask for and offer help to other Alfresco Content Services Users and members of the Alfresco team.
Related links:
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.