I have an action that does a few things to the NSManagedObjectContext, and they're all surrounded by begin/endUndoGrouping (A). Later, a timer checks on a managed object and sees that an outside change has been made (the mod date of file the object refers to has changed), so one attribute (modificationDate) on the object is updated, which I have bracketed with disable/enableUndoRegistration (B). At this point, if I click on the Edit menu or hit command-z, the undo manager runs a checkpoint, and the MOC ends up adding a separate undo to the stack, I assume for the change caused by B. This mystery undo has no name, because I didn't create it and set its name, and as far as the user is concerned, it's not an action they did, so it shouldn't be undoable, and the changes aren't user-facing in the first place.
Why is this misbehaving? The method in the invocation for B is _undoUpdate: and the target is the MOC. It should not be on the undo stack.
I see that NSManagedObjectContext has a private ivar called _ignoreUndoCheckpoints, which sounds exactly like a things I'd like to turn on, if it does what it sounds like it does. But there's no public interface for it.
