Version and Object Deletion and Version Rollback #13
Labels
bug
Something isn't working
enhancement
New feature or request
help wanted
Extra attention is needed
Rather Hard
This might be rather hard to achieve
Milestone
Some thought is needed around what should happen viz verifiability" and UX when
Versioned::onAfterRollback()
orDataObject::onAfterDelete()
are called. This is legit behaviour in SilverStripe, and for CMS users in any system (programmatically too), but goes against the grain of verifiability if one can no longer verifiy becuade an item is not immutible.We could disallow rolling-back to previous versions if it's verifiable - and if indeed it's even a problem (Can we revert back to the version prior to rolling back!!?). Also "Deletion" in a Versioned context means "archived" right, so it's still available?
But so far, the module deals only with verifiability on the pretext that records exist in some way, they've just been changed. What about if a version was hard-out deleted? Then the current model falls over, as a CMS author can not be reasonably expected to remember all available versions of all her versioned pages (for example).
One idea is to create a cron-task that periodically queried Tierion for hashes submitted by our system. But becuase the module doesn't know what it doesn't know viz deleted DB records, this implies that our hashes have a unique signature (or are really encrypted strings, salted with a known nonce - e.g. a nonce that is at least the same across all versions of a given record - nonce-like if you prefer). This means that theoretically, logic could be written that queries the DB for all nonces, and for each hash composed of each nonce, pulls the related proofs out of Tieron (How!!?). A comparison is then made against the database where we diff known, local hashes with those out of Tierion. Should a discrepency occur we might be able to calculate or infer for which SiteTree record, a version is missing.
The text was updated successfully, but these errors were encountered: