DPlan maintains a 50-step undo/redo history in memory for the duration of your session. Every structural change to the project is captured as a full snapshot, giving you a reliable safety net when experimenting with schedules, restructuring task hierarchies, or recovering from accidental deletions.
| Method | Undo | Redo |
|---|---|---|
| Keyboard | Ctrl+Z (Windows/Linux) · Cmd+Z (Mac) | Ctrl+Y · Cmd+Y |
| Ribbon | HOME tab → Undo button (↩ icon) | HOME tab → Redo button (↪ icon) |
| Title bar | ↩ icon beside the project name | ↪ icon beside the project name |
The undo and redo buttons are greyed out (disabled) when there are no steps available in that direction. A tooltip on each button shows a brief description of the action that will be undone or redone (e.g., "Undo: Delete task 'Design wireframes'").
Every operation that modifies the project data model captures a full JSON snapshot before the change. The following operations are all undoable:
The following actions are outside the undo scope:
The undo history holds a maximum of 50 snapshots. When the 51st undoable action occurs, the oldest snapshot is evicted from the bottom of the stack to make room. This means very old actions become permanently unavailable for undo.
50 steps is generous for normal editing sessions. If you are about to make a large batch of changes (e.g., restructuring the entire WBS, bulk-editing many tasks, or running Auto Schedule after a major scope change), save a .dplan file first. The file gives you a permanent fallback beyond the undo stack's 50-step window.
DPlan's undo system uses a full-state snapshot strategy rather than a command/inverse-command pattern. Before any undoable action, the entire project JSON object — tasks, resources, dependencies, baseline, calendar — is serialised and pushed onto the undo stack.
This approach has two important characteristics:
The undo stack lives exclusively in JavaScript memory (a plain array of JSON strings in the page's runtime). It is never written to localStorage or any file. When you close the tab, refresh the page, or navigate away, the JavaScript runtime is destroyed and the stack is gone.
The project data itself (the current state) is auto-saved to localStorage on every change, so you will not lose your latest work — but you will lose the ability to step back through pre-session history.
When you drag a task bar or milestone diamond on the Gantt, the undo snapshot is captured at the moment you release the mouse button, not during the drag. This means mid-drag positions are not recorded. If you drag a task bar to a new date and then decide it was wrong, one undo step returns the task to exactly where it was before you started dragging.
Similarly, resizing a bar by dragging the right edge records a single undo step on mouse-up.
When you save a recurring task configuration in the Task Editor and DPlan generates the repeating instances, all generated rows are captured in a single undo step. One Ctrl+Z removes all the generated instances and returns you to the state before generation.
This is intentional — you typically either want all the generated instances or none of them. See Recurring Tasks for details.
The .dplan file always contains the current state of the project — the same state that is in localStorage. It does not contain the undo history. Saving a file does not affect the undo stack in any way: you can save a file and continue undoing through the same history you had before saving.