Overriding object_changes on paper trails to store name corresponding to change in IDs

Question

For associations, I am assigning IDs from different model to my model and therefore IDs are being changed. Papertrail tracks those changes, and this is the state of my object_changes:

{
  "updated_at": [
    "2023-11-13T08:54:26.346Z",
    "2023-11-13T08:56:06.961Z"
  ],
  "paying_id": [
    "ID1",
    "ID1 new"
  ],
  "company_ids": [
    [
      "ID1",
      "ID2",
      "ID3",
      "ID4"
    ],
    [
      "ID1 new",
      "ID2 new",
      "ID3 new"
    ]
  ]
}

However, in my view for the audit logs, I do not want to display the IDs, but display the names corresponding to those IDs. Right now, I am using if loops to query the names and send to the view. But there must be a better way than this. The docs is also against overriding object_changes, but if object_changes is not overriden, then how?

What is the correct way to do this?

Answer 1

I would keep the logs as is, storing only ids in the logs. I would also make the Company records soft-deletable, meaning when the company is destroyed, it is not really removed from the database, but becomes "invisible" to Rails in default workflow. You could implement your own soft-deletion logic or use one of the gems, i.e. paranoia

Because imagine, what happens if the Company name changes for an existing company? If you duplicate the Company name someplace else as a string, you would end up with inconsistent data.

If you really want to go with the logs, you could use meta to store the Company's name only in case the company_ids field has changed. Something like

has_paper_trail(
    meta: {
      company_names: proc { |item| item.company_ids.changed? ? list_of_company names : nil }
    }
  )

But I'm not sure the _changed? or _previously_changed? are available in this scope. This will also generate a huge string, depending on the number of companies. Alternative would be to store a hash with two keys list_of_added_company_names and list_of_removed_company_names which is somewhat better, but still produces data duplication.