05-05-2018 03:53 AM
Hi All,
We started displaying audit trail on our alfresco instance with the help this link but later we figured out some issues with this approach e.g. when a doc was moved all the audit trail was lost for the doc as the audit trail was calculated based on nodepath of the doc so we decide to move to noderef but alfresco access doesn't capture noderef though it produces it.
Therefore, we decided to build our own audit application similar to alfresco-access but capturing the node now with the help of this link. It worked well but the moment we tried to fetch the audit of existing docs we got to know that audit won't show up for them; it work well for new docs.
So now as I see I might need to override the existing alfresco-access-audit.xml file and include the node capturing RecordValue tag in it(not sure whether this will help) but so far I am not able to, I have kept the alfresco-access-audit.xml under alfresco/audit in my repo project(Please correct me here how I can override the file if I am doing wrong) as putting under alfresco/extension/audit didn't worked for me.
Here is my java class and here is my overridden alfresco-access-audit.xml file.
So I want to know
1. Will overriding alfresco-access-audit.xml help me show the audit entries of previous docs as well as new docs.
2. Is there another way by which I can overcome this issue.
Thanks
Hiten Rastogi
05-07-2018 07:13 AM
a) Do not override alfresco-audit-access.xml or in any way change the default alfresco-access audit app. Any Alfresco or third-party addon may depend on it and you would break their functionality. Instead, build your own audit app under a different name and simply use the same data sources in your mapping, and you should be fine. Of course the lookup to display the audit trail would then have to use your custom audit app...
b) a RecordValue element on the node should be fine
c) You realise the file name is all wrong - the original file is called alfresco-audit-access.xml and you called yours alfresco-access-audit.xml
d) There is no override feature for audit configs using the extension path - audit XML files will be read from all these places, and only the first to register a particular audit application will win.
05-07-2018 11:07 PM
Thanks Axel for your input but unfortunately I am still in search of the answer. And Yes, the name is wrong but it is just a typo from side else the name that you pointed out is the one that I have at my end. Sorry for this.
Let me be more clear and precise this time.
We were earlier using alfresco-access application for viewing the audit data which had nodepath as the search key in the AuditQueryParameters object but as I stated this apporach had some issue that when a node is moved or deleted the audit entries were messed up.
As you pointed out in the IRC chat that nodepath should not be used instead it should be noderef and as the /alfresco-access/transaction/node is not captured by default by the alfresco-access application I did created by my own audit application evAudit similar to alfresco-access with just one more RecordValue in the transaction path for /alfresco-access/transaction/node.
Everything worked well, the previous issue that occurred due to the use of nodepath got resolved but then I got stuck into another issue and for this issue I am looking for an answer. The issue is that when my new audit application applied on the DMS instances that were using alfresco-access as the audit application there is no audit generated for the documents already present in the DMS by the new application but it is getting generated for the new documents.
Now as far as my knowledge in alfresco goes this is happening because the audit entries for those docs that were there previously was obviously not captured by my new audit application and the only solution that I can foresee is that by overriding the OOTB alfresco-access application audit xml file but even in this case I believe it will not work as /alfresco-access/transaction/node RecordValue was not captured for the docs already in the DMS.
I hope I have made myself clear this time as to where my issue lies and what I am trying to achieve. Please let me what I can do for the above.
Thanks
05-08-2018 03:27 AM
Of course all the old audit data will not be affected by your new application / changed audit config. There is no way to (reliably) get the new data for old events since nodes may have moved / been deleted etc. Technically, one could try to process the old data, use the path (where possible) to resolve the node (if still existing at that location) and "replay" / "copy" the audit data into the new application. But again, due to node path being shifty, it is very unreliable...
So, yeah - nothing can be done in that regard really.
05-10-2018 02:22 AM
Thanks Axel,
I will have to resort to finding the audit entries from nodepath for the nodes that doesn't contain audit with noderef and for all other I will use nodeRef.
Thanks for helping me here.
01-31-2022 01:34 AM
@afaust
How is it then that the path is used as the only "identifier" for the node in question, even though it is "shifty"?
Wouldn't NodeRef or DbId be better / important additional identifiers then? (I'm facing exactly the same issue.)
These would help link the logged data to the entities involved.
01-31-2022 01:50 AM
The DB ID would be "shifty" as well, since it is not guaranteed to stay constant for the same document. If you accidentally delete a document and then restore it from the trashcan, it will have a different DB ID.
The NodeRef is the only stable identifier. Why Alfresco hasn't included it in the audit data is a question to which I don't have the answer. I have always considered the alfresco-access audit application a mere sample, and tried to not use it at all for production-grade customer solutions, in which I dogmatically use the NodeRef as an identifier.
01-31-2022 05:33 AM
Explore our Alfresco products with the links below. Use labels to filter content by product module.