Seeing who changed a record, and undoing it
In a shared table, somebody will eventually change a value that was right. The useful questions are then who did it, when, whether it was a person or an automation, and how to put it back without disturbing what other people changed afterward. This post describes how Appdor answers them, including the cases where it declines to.
Where the history is
Open a record and use Show activity. The panel lists the changes made to that record, newest first. Each entry gives the kind of change (insert, update, delete or restore), who made it, when, and for updates the fields that changed, shown as the old value struck through and the new value after an arrow. Values are formatted the way the column displays them, so a status reads as its label rather than an internal identifier, and a select option that has since been renamed is shown under the name it had at the time where the schema history covers that moment. If an entry touched more than four fields, the panel says how many more there are. A selector labelled All fields narrows the list to the changes that touched one field.
The panel loads the most recent fifty entries. When there are more, it says so: it shows the most recent changes and states that older activity is not loaded. That sentence matters, because the restore tools below are limited to what is loaded.
Who made the change
The actor is the person, or the integration, that made the write. An entry whose actor was not recorded is labelled as such, in the panel's words "actor not recorded", rather than being given a stand-in name.
Changes that did not come from someone typing in a cell carry an origin, shown beside the name. The write origins the product recognises are interface, API, automation, import, sync, connector, migration, recompute and system. An automation's write is stamped for exactly one statement, so a later edit in the same transaction is not mislabelled as automated. A change made by a record script is shown with the script's name and run, in the form "script", then its name, then "run" and an identifier, rather than as a pair of identifiers. Each row written by an import is stamped with the import run it came from.
Reverting one change
An update entry that changed fields offers Revert this change. It sets back only the fields that entry changed, not the whole record, so a field someone else edited in between is left alone. Insert entries are not revertable this way, since that would amount to emptying the record, and delete and restore entries change whether the record is deleted rather than the values in its fields, so they are not reverted field by field.
The button is shown only to someone whose role can write records, and the database refuses the write otherwise. The undo goes through the same validation as any edit, evaluated on the restored state, so a rule added since the original change still applies. It is also conditional on the record not having moved: if the record changed elsewhere while you were looking, the panel says "This record changed elsewhere — reload before undoing" instead of overwriting.
Viewing and restoring a past state
View as of this point previews the whole record as it stood after that change and lists the values a restore would write. Restoring is then a separate step. The preview is honest about what it cannot do:
- A field added after that point is emptied, not removed, because a record write merges and a field cannot be deleted by restoring. The panel tells you how many fields will be emptied.
- Computed or automatic fields are left alone.
- Values that belonged to a column that no longer exists cannot be written back.
- If the point you chose is older than the oldest loaded entry, the restore is refused rather than answered from the current row, which would label a mixture as a past state.
A restore is itself an ordinary update, so it appears in the history. The panel does not currently link it back to the entry it was restored from.
What the history will not show you
History respects field permissions. A field you may not see is removed from both sides of every entry, so a change to it arrives as an entry with nothing visible in it, and the panel says "No field you can see changed". The browser cannot edit or delete history entries.
On retention, the product's own retention document says the record change history is kept indefinitely by default, and that an operator can set a window. Deleted records sit in the table's recycle bin for 30 days before they are purged, which is a separate mechanism from history.
If a mistake needs undoing today, open the record, open Show activity, and read the entry before you press anything. See Appdor