#301 Author History shows invalid data

[Ahasuerus]

Author History shows two types fields for each edit logged in the history table:

1. Fields that were changed during the edit;
2. Fields that were not changed during the edit.

The former are displayed correctly, but the latter are recreated from the current values stored in the database, which may not be the same as the values that existed in the database at the time of the actual edit. We need to either remove the second type of fields from the page or add a note explaining how they they are derived.

[Uzume]

I always thought the history was highly questionable in light of the fact that we already have a history of all submissions:

1. Fields and values that were changed during the edit are already in the submission(s) but previous values are not saved.
2. Fields that were not changed during the edit can be surmised from the submission(s) but the values are not saved.

This means to have a useful history (beyond what the submission queue/history already provides) one would effectively have to snapshot each record (i.e., all related table entries; different record types would have to be handled separately) before submission changes are applied to database--note that such data likely would be considerably larger than the submissions themselves (the exception would be rejected submissions which would result in no history).

[Uzume]

The other issue with any history concept is that the types of submissions handled do not correspond 1:1 with record types and some submissions can yield changes to many records (e.g., pub changes can result in many author and title changes, etc.). Should this be handled in many history entries or a single? If a single, this means it corresponds with no existing record type (so what type of history is it and how can that be usefully queried and used?).

I frankly do not see the value of any history concept unless these types of design issues can somehow be overcome. The only method I can see of creating a useful history is snapshotting records--including possibly multiple snapshots per committed submission. The problem is the size and the return on investment (ROI) of such a proposition.

[Ahasuerus]

When "Edit History" was implemented for all record types in 2020-2021, the design of the new functionality accepted that there was no realistic way to address the issues outlined in this Bug report. Instead of trying to address them, the new design made them explicit and warned ISFDB users about these limitations. Closing the Bug report.