How-To: Restoring Deleted References to Deleted Records

[Brian Dailey1]

Following is a generalized script of one I initially developed to help a user with recovering the assignment group values after a restored deletion (How to revert the Assignment groups for legacy incidents? )

Restoring an item from Deleted Records does not restore values in the tables that originally referenced the deleted record (they would have been cleared by the deletion process since they were no longer valid).

However, the information is stored as flat string values in the Audit table and can be recovered and re-associated once the deleted records themselves have been restored.   So, the procedure is very simple:

1. Restore the deleted records using the Deleted Records module.
2. Run a server script (Fix, Background, etc.) that calls the function restoreReferences(tableName, fieldName) with your table and field names.

function restoreReferences(tableName, fieldName){

var brokenRecord = new GlideRecord(tableName);

brokenRecord.addNullQuery(fieldName);   // No use processing records where there is still an AG

brokenRecord.query();

while(brokenRecord.next()){

        var lastFieldValue = new GlideRecord('sys_audit');

        lastFieldValue.addQuery('documentkey', brokenRecord.sys_id);

        lastFieldValue.addQuery('fieldname', fieldName);

        lastFieldValue.orderByDesc('sys_created_on');

        lastFieldValue.query();

        if(lastFieldValue.next()){

                  brokenRecord.setValue(fieldName, lastFieldValue.newvalue);

                  brokenRecord.update();

        }      

}

}

[Brian Dailey1]

I later realized one caveat to this method, the table must be audited.   But as long as that's true, this method is good to go.

-Brian

[sachin_namjoshi]

Hi Brian,

Do you have solution for restoring references from non-audited table?

Regards,

Sachin

[Brian Dailey1]

Hi Sachin,

I have not tried this with a table that was not audited.   Off the top of my head, I don't think there is a way to do this same procedure if the field is not being audited, simply because you must have something that retains a memory (however hazy) of the association between your (recovered) deleted record and everything else.   The audit table manages this because it stores everything as flat string values and is unaffected by cascade deletes to reference values when a record gets wiped out.

If you could find another table that stores information about a relationship between the record that was deleted and other records, then you might be in business.   You just have to understand that relationship to engineer a solution (e.g., like using the current record's sys_id and the missing record's referenced field name to look-up values from [sys_audit]).

Coincidentally, I just realized that the original solution could probably be used in the case where a field itself has been deleted from a table definition and then recreated.   The field data would be lost, but the theory should remain the same (you could leave out the null query, since they'd all be empty).

-Brian

[pvl]

Hi Brian,

Are you sure this script is working? As I checked in the sys_audit table oldvalue as well as newvalue has been set to DELETED.