Last Audit and Purge Date

Hello all,

I have been searching for the last month or so trying to find a way to extract the last time an Audit and Purge was executed on a revit file. I have had absolutely no luck finding anything. Have any of you seen a post or something to send me in the correct direction?

Thanks for your help,
Steven

I wonder if the Journal file contains any of this info? Other than that I am not sure that info is saved anywhere, but will be interested to see what others might say.

I was looking through Andreas Dieckmann latest family Journalysis on GitHub but I did not see anything. I know he is still working on it so maybe in time. I had the same thought as you but have not found anything in the Journal.

I know Purge is not accessible (last time I check) in the API so I unfortunately am thinking the dates are not attainable.

Journals do in fact contain dates for both sets of data (really they contain pretty much everything), but it won’t be easy. First obstacle will be figuring out how to get the dataset, which is every journal file for every team member which was created during the analysis period. These can be found here:

%LOCALAPPDATA%\Autodesk\Revit<Product name and release>\Journals

Since these are saved in their user profile you can’t just log in as a different user and grab them yourself unless it’s an admin account for the machine. Talk to your IT department to see about how to go about getting these some other way. Once you overcome that issue and get all the files, you can really see the scale of your request: there is a new journal file created every time a user opens Revit - so if they close and reopen it every two hours there will be 20 journals in a week. That’s a lot of files on a team of 10, and file names (but not paths) will overlap in some cases as the names generated are just a number sequence.

Not only are there alot of files here, but the files have a lot of data in them. Every command (even mouse movements and clicks) is recorded so it’s a LOT of data to look though. With all the files, you are easily looking at a few million data points.

The audit and purge commands are easy enough to find once you get the data set. Search “audit” and “purge” in your most recent journal (assuming you’ve both audited and purged in your last Revit session) to see what I mean. Keep in mind there are additional commands entered between the initial “audit” and “purge” entry and the actual command execution. Things like those pop up windows where you have to hit “ok” or “cancel”, the “select all,” “select none,” or individual selections, heck even closing the window counts. So look for the completion of these. Transaction OK is a good indicator.

Finding the completed command and tying it to the correct document is simple enough for the audit command as the “audit” entry will always be a little bit above the open command. Unfortunately, this isn’t the case for the purge command. Because a user can have multiple documents open in the same session, and that the purge command isn’t associated with something which always indicates the active document, you need to confirm which document was purged. This happens somewhere above the command. So after you find the completed purge command you need to comb backwards in the journal file to get the name of the document which was active when the command was run.

So while it’s doable, I wouldn’t recommend it. Journal mining is a big, complex thing. It should really only be done when you’re dealing with a current, active issue. Attempting to go backwards and find when stuff was running correctly, while doable, isn’t fun and will cost you more time than you’ll gain from it.

The best way to find when a file was purged? Look at the file size over time. If the file size is reduced, it means someone ran a Purge command (unless someone deleted a sizable part of the model, which the team would likely know about). The historic file sizes can be taken from backups, but is more useful when logged periodically in a spreadsheet or csv.

The best way to find when a file was audited? Assuming it’s not in the slog files (a long shot as I don’t see any difference between open and open with audit in my test file), my guess is that the journals are in fact the best method. However, that would be so painful I wouldn’t bother.

Personally I always lived by this rule for audits on my projects: If I have to ask when the file was last audited, it’s been too long so do an audit right now. :wink:

2 Likes

@Steven - This can actually be done fairly easily with Journalysis in its current state. I added two samples on GitHub to demonstrate how:
https://raw.githubusercontent.com/andydandy74/Journalysis/master/samples/Journals_AllAudits.dyn
https://raw.githubusercontent.com/andydandy74/Journalysis/master/samples/Journals_AllPurges.dyn

5 Likes

Jacob,

Thank you very much for the reply and for the depth of the reply. I would agree this sounds too cumbersome. I am trying to build a health dashboard and wanted to include the dates for the BIM manager to see. I would agree that if the thought crosses your head then you probably should audit and purge. The only problem with this is the people working on the project who do not have the thought.

Our start up view has an input for the date of the last audit and purge but it is hard to get people to 1) look at it and 2) enter the information when they do an audit or purge.

I will keep brain storming and trying to find the best way to do this and report back to here if I find something.

Andreas,

Thanks for the sample files. Seams simple enough to collect the data. The only problem is collecting the correct journal file or collecting every journal file and culling through all the data. I will keep this in mind and see if there is anything that can be done. Thanks for your help and time.