Version history of findings, finding templates, designs

[aronmolnar]

It is currently not possible to see if changes were made to a finding in a report, who did changes, when and what the changes were.

We could introduce a version history to resolve this.

This could also be applied to finding templates and designs.

Challenges might be:
• What triggers a new version and how often/how many?
• Complex implementation of diff in frontend

[noraj]

• What triggers a new version and how often/how many?

Each save when auto-save is off. For auto-save on, it's challenging to define check points (amount of time, number of chars/lines changes, or just define checkpoints when the save button is pressed manually (counterintuitive)).

[MWedl]

We decided to use a combination of fixed checkpoints when certain fields change and time-based checkpoints.

Fixed checkpoints will be created when certain fields change that have a bigger impact on the state of the saved object. For example when an object is created/deleted, a project is marked as finished, the project design (and therefore the set of available fields) changes or the status of an finding/section/template-translation changes (e.g. from "Initial" to "Finished").

Additionally there will be time-based checkpoints that handle auto-saves. One checkpoint will be saved every 2 hours for each user that edited an object. When users pauses editing for some hours or days the last state of their changes are saved. If other users change something in the meantime (and override text), it is still possible to view the object at the time where users left off.

About the technical implementation: First, we tried to create checkpoints only when needed, but this did not work well and we were not able to create checkpoints in some situations where they would be useful (e.g. checkpoint before users pauses editing scenario described above). Therefore, we decided to create a checkpoint for every API request that changes data. This produces a lot of data and spams the history timeline. In order to keep the historic data at a reasonable amount, useless time-based checkpoints will be cleaned up afterwards in a scheduled task. Fixed checkpoints will never be cleaned.

[MWedl]

Implemented in https://github.com/Syslifters/sysreptor/releases/tag/2023.128

Version History is only available for SysReptor Professional