Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

A novel approach to Undo


Published on

Modification audit logging and using zc.beforestorage to time travel. From #ploneconf2016 presentation, this is an idea for supporting a new kind of Undo in Plone 5.x.

Published in: Software
  • Login to see the comments

A novel approach to Undo

  1. 1. A novel approach to undo Modification audit logging and using zc.beforestorage to time travel. Sean Upton / UPIQ #ploneconf2016 | @sdupton
  2. 2. Disclaimers • Experimental approach • Unfinished work in progress • I’m here to pitch an idea about undo, whose principles have been field tested… – ... But we need a UI for this. – .... I’m working on it. • Today, we’ll look at the pieces and talk about them. • Maybe find a way forward for practical undo? #ploneconf2016 | @sdupton
  3. 3. Motivations • Reasonable degree of interest on Github and Twitter. • Some of my users cost me hours fixing human errors with programmatic monkey-wrenching. • If we can use this programmatically in repeatable ways, we can make something user-facing, no? • Because we cannot use ”Undo” to undo. #ploneconf2016 | @sdupton
  4. 4. The basics: audit logging • Audit log of all changes, stored in ZODB – Logging now is synchronous, may be async in future, TBD. – Log all of: • Deletion • Modification • Move • Addition – Log independent of Catalog. – Handlers call logging system • Logging components adapt site, use annotations. #ploneconf2016 | @sdupton
  5. 5. Audit logging: usage • Core components tested, but… still needs a good UI. • Outside of core use case, this could be used for regulatory audit requirements (e.g. HIPAA). • UI plan is enumerating in views: – A view to enumerate changes, by “facility” – A view to prune changes • We may need better possible ZODB conflict resolution strategy for queuing (LIFO insertion) of modification facilities logged. #ploneconf2016 | @sdupton
  6. 6. Okay, so you log every change? • Right, and we will have view to enumerate these changes, in reverse chronological (insertion) order. – With filtering – With batching • For regulatory logging, you could to this to a data retention threshold before pruning, or not prune this at all. The change records are small. #ploneconf2016 | @sdupton
  7. 7. Facility • For each type of change we have a facility: – Modifications – Deletions – Additions – Moves / renames • Each logs records with: – UID – Path – Authenticated user – Timestamp (python datetime, currently local time) #ploneconf2016 | @sdupton
  8. 8. But what do we do with this? FIX HUMAN ERRORS! #ploneconf2016 | @sdupton
  9. 9. The plan • I have used zc.beforestorage multiple times to fix human errors, each time programmatically. • If what you have is within your kept history, going back in time is easy. • We want to make this user-facing, not a programmer’s problem. • I’m creating a package called plone.wabac as a transitional/experimental proof of concept. – Now soliciting collaborators! J #ploneconf2016 | @sdupton
  10. 10. plone.wabac • WABAC == “wayback” • Transitional add-on • Half-finished • May get exploded and federated elsewhere. • Assumed goal of eventual PLIP, once proven. • Want this to be testable by users, uninstallable in meantime. #ploneconf2016 | @sdupton
  11. 11. Restoration, not “Undo” • We want to restore item to previous known- good state: – Before accidental deletion – Before modification that was problematic. • This might compete with CMFEditions, so may be a non- problem. • But my site stores non-content ZODB stuff on content objects, so I cannot merely use CMFEditions for rollback. – Before renaming or moving. • User picks item from audit log, and clicks “restore”. Or more than one item at a time. #ploneconf2016 | @sdupton
  12. 12. zc.beforestorage • Time-travel through your kept history. • !! Requires you keep history. • !! Requires you keep enough history. – We could use this on kept FileStorage backups too, if we were clever and did not want to only go through live history. • But that is not in scope yet, requires configuration. • Mostly, I want to undo things easily when the “Oh ****” phone call comes in. – Or better, tell the site admin how to fix it. #ploneconf2016 | @sdupton
  13. 13. Programmatic use • Load storage wrapper programmatically. • setSite() on the time-travelled version. • Get your content; • ZEXP export it; • setSite() on live target; • Restore from ZEXP. • Repeat. – Show example code #ploneconf2016 | @sdupton
  14. 14. Security disclaimers • We might want to be able to stop ability to undo things (e.g. delete something very bad, very quickly, and very permanently). • My vision now is a site-wide audit logging facility accessible to Site Administrator or Manager role. • We can make this placeful if we index audit trail by path. – Not yet in scope. – Need to ponder permissions for restoration. #ploneconf2016 | @sdupton
  15. 15. Next steps • Finish the UI for enumeration, filtering, and pruning of audit data. • Come up with reasonable tactic for avoiding conflict for audit logging key insertion. • Views and adapters for restoration via zc.beforestorage. • Logging the restorations themselves. • Prove concept universally useful, then PLIP it? #ploneconf2016 | @sdupton
  16. 16. Questions? … and feedback via: #ploneconf2016 | @sdupton