Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version and Object Deletion and Version Rollback #13

Open
phptek opened this issue Jun 29, 2018 · 0 comments
Open

Version and Object Deletion and Version Rollback #13

phptek opened this issue Jun 29, 2018 · 0 comments
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

Comments

@phptek
Copy link
Owner

phptek commented Jun 29, 2018

Some thought is needed around what should happen viz verifiability" and UX when Versioned::onAfterRollback() or DataObject::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.

@phptek phptek added 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 labels Jun 29, 2018
@phptek phptek added this to the 2.0 milestone Jun 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

1 participant