a novel approach to undo

A novel approach to undoModification audit logging and using

zc.beforestorage to time travel.

SeanUpton/UPIQ

#ploneconf2016|@sdupton

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?


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.


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.


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.


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.


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)


But what do we do with this?

FIXHUMANERRORS!


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


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, uninstallablein meantime.


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

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.


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


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.


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?


Questions?

… and feedback via:


a novel approach to undo

Software