Find the user of the deleted Element in Revit

[Rajamanickam.G]

Is it possible to get the name of the user using Revit API who deleted the Element from Revit collaboration model?

Thanks in advance.

Best regards,
Raja.

[jeremy_tammik]

No sorry. In fact, even worse, you cannot retrieve any information at all about deleted elements. The element is deleted and all its data is gone, afaik. If you wish to track it, you need to cache its data before deletion.

[RPTHOMAS108]

Yes as Jeremy noted  it is pretty difficult. You could log the ElementIds against username but there are mainly two issues with that:

1. The ElementId may have changed from what you later check against to identify the element from the id (old copy of model).
2. The element is only deleted in central during synchronisation and that happens along with a load of other changes which are not monitored by the API. So even if a locally generated log says the element was deleted you don't know if that change was pushed through to central i.e. Delete > Undo > Synchronise (there is no recording of Undo just the ability to log the deleted and the synchronisation). 

Seems to be a recurring theme that people want to know more about the deleted items, what would be the motivation? The element is no more...it is an ex-element! If you don't want something deleted it seems better for users to run an add-in that marks the element then either posts a failure or cancels an event when deletion is attempted.

[Rajamanickam.G]

Thanks for your quick confirmation Jeremy.

[Rajamanickam.G]

Thanks for your reply. The real purpose of tracking is to monitor if the project runs smoothly and the users do their job properly. We really want to avoid policing but some users just wanted to avoid accepting the mistakes and do the blame game. This causes a lot of time waste and additional stress to the BIM Coordinators\Managers.

Is it possible to track it with some kind of Logging outside Revit DB when something like delete event happens in the central model? Would it be a good idea to log the unique ID of element instead of Element ID ?

[jeremy_tammik · Accepted solution]

If you just want to track whether people are deleting a lot of elements in general, you can very easily implement a DocumentChanged event handler that is notified when elements are added, modified and deleted. The affected element ids are provided. However, as noted above, no further data is available for the deleted ones. Here is more on DocumentChanged and the more complex and powerful DMU framework:

https://thebuildingcoder.typepad.com/blog/about-the-author.html#5.31

Here are more thoughts and a PoC on tracking model modifications in general:

https://thebuildingcoder.typepad.com/blog/2016/03/implementing-the-trackchangescloud-external-event....

[RPTHOMAS108 · Accepted solution]

In practical terms you would be using:
DocumentChangedEventArgs.GetDeletedElementIds from Application.DocumentChanged
or
UpdaterData.GetDeletedElementIds from IUpdater.Execute

You can't get UID from these since the element is no longer available to look it up on.

I rack my brains to think how you could do this without implicating the wrong person but I think the simple answer is whatever method you use system failures could lead to the wrong person being implicated.

As an extreme example:

Evertime Application.DocumentSynchronizedWithCentral occurs you make a copy of the central and store it somewhere. By comparison of time stamps or information added to the central you can tell who synchronised that copy.

However what if copying failed leading to a missing record. Under that circumstance the last record shows the element missing but perhaps that was just because they acquired the change from elsewhere via ReloadLatest.

It's a human management issue no? If you have two production lines with two people on each and on one of those lines they are pointing the finger at one another then swap one of those with one from the other production line. In the end you'll find the common denominator(s). Also they have to address the atmosphere and what leads to the person not being open about the mistakes they've made. There used to be this idea in construction that mistakes are so critical to identify that you have to foster an atmosphere where when somebody makes a mistake they can be open about it. A 'first mistake = last mistake' atmosphere leads to a situation where the mistakes are left to reveal themselves.

The other issue is that in the end someone deleted it but someone should spot it missing. If a drawing goes out with a missing column for example then that is a systemic problem. There should be more than one person at fault in that scenario or it points to someone being overburdened with both production and final checking (akin to an overburdened defender in chess). Any system will fail if it doesn't recognise that humans operating within it are not infallible. If the error was spotted before there were major consequences then that is worth recognising as the system working.

As a developer I would tend to focus on what can be done to enable users not to make such errors. As noted previously there are mechanisms to protect things considered unchangeable. There are even therefore ways of restricting what categories or individual elements a particular user can change.

[sragan]

Its not an API solution, but honestly, I think the best solution is to Pin important things you don't want deleted.  Its kind of a pain, because to move or edit anything that is pinned, you have to unpin it and then re-pin it.   

But a user can't delete anything that's pinned without unpinning it first.   That does stop a lot of non-intentional deletions.   

[jeremy_tammik]

Many thanks to Steve and Richard for your insight! Preserved here for posterity:

https://thebuildingcoder.typepad.com/blog/2021/12/logging-and-monitoring-deleted-data.html#3

[matthew_taylor]

A little late to the game here, but I saw this post mentioned in @jeremy_tammik's blog.

The simplest way to track deleted elements is by iUpdater, as that remains synchronised with the document state.

The trick to recording element deletion and maintaining some inkling of what the element was is to have a lookup table. The lookup table should be initialised once, and then maintained via iUpdater (added/modified). The key for the lookup table should be the elementId. The value could be a simple description such as:

Wall;300RC;0,0,0;10,10,0;3.0;Concrete;2021-12-21

(Category;Type;Start Point;End Point;Height;Material;Added/Modified Date)

This lookup table could be very large if all elements are monitored (or if descriptions are long). If only a few categories are monitored, storing the lookup table in a DataStorage element would work. For a vast number of categories/elements etc? Something like MongoDB would do just as well. It wouldn't matter if the data was a little stale.

Another way could be to redefine the Delete command. In the redefined command you would capture the element details, then proceed with deletion. An iUpdater could then process the data.