Safer ways of deleting notebooks - or undoing delete?

[psychemedia]

[Picking up on a googlegroups thread: Disable "Delete Notebooks" option....]

After mistakenly deleting a bundle of (fortunately) backed up notebooks, I wondered if there might be safer ways of managing this interaction.

If I have currently selected a number a notebooks, clicking the red delete button currently prompts me for confirmation with the message Are you sure you want to permanently delete the N files/folders selected?. I'm often blond to these messages, and if for some reason I don't check which notebooks are ticked I could delete many of them by mistake.

One way to reinforce the confirmation message might be to show a list of notebooks to be deleted in the confirmation dialogue, along with pre-ticked checkboxes that show exactly which notebooks are about to be deleted, allowing you to uncheck ones mistakenly included in the deletion list.

Another option identified in the thread was an option to undo a delete, with 'wastebin cacheing' enabled for thirty days, for example. (I wonder if the checkpointing mechanism can be appropriated for this, redirected to a wastebin area?)

For the paranoid educator in me, being able to disable or move the delete notebook button somehow (a custom.js tweak was suggested in the original thread, but I'm not sure what to disable?) could be a good option.

[Carreau]

along with pre-ticked checkboxes that show exactly which notebooks are about to be deleted, allowing you to uncheck ones mistakenly included in the deletion list.

That is IMHO too much or need a confirmation dialog to confirm that what you have ticked it correct.

[jasongrout]

+1 for a trash folder somewhere you can restore from

[Carreau]

This seem like generic enough that there should be a library for that. This would require a refactor of the content manager though if we want an undo in the UI.

[damianavila]

+1 for a trash folder somewhere you can restore from

:+1: too... I think is a sensible option...

[takluyver]

Send2Trash is a way to use the OS-provided trash mechanism, which should probably at least be an option, and possibly the default (since server admins are more likely to configure things like this than desktop users).

I don't think desktop 'recycle bins' are very well designed - as I described before, I think users tend to end up either bypassing them entirely, or accumulating thousands of 'deleted' files. But they are there, and for desktop users, I think it's better to use the existing trash mechanism than come up with our own system.

[takluyver]

Unfortunately, as the name suggests, Send2Trash doesn't appear to have any APIs for retrieving a file from Trash, so the 'Undo' button might have to be left out with desktop integration. I'll make an issue asking about it, but development looks a bit dead.

[ssanderson]

How would this work with other ContentsManager implementations? Would providing the ability to restore a deleted file become part of the ContentsManager's responsibilities? @Carreau w/r/t jupyter-drive, for example, does Google Drive have that kind of functionality built-in?

[takluyver]

Yes, I'd guess it would become part of the ContentsManager's responsibilities. Though we could do things in such a way that it's optional for ContentsManager implementations to provide.

[minrk]

There's precedence for optional trash behavior. Some mounted remote filesystems don't support trash, in which case the standard delete action prompts with "This will be permanently deleted" confirmation.

One significant change - moving to trash doesn't typically have a confirmation, so if we add it, I would probably either have trash or a confirm-delete dialog, but not both.

[takluyver]

Yep, one of the big advantages of trash is that we could skip the confirmation, because deleting is no longer a destructive action.

[psychemedia]

@Carreau "That is IMHO too much or need a confirmation dialog to confirm that what you have ticked it correct."

What I'm thinking is if I have accidentally ticked a lot of files, I can easily be blinded to "delete N files". I did originally think that clicking the delete button could then highlight the files to be deleted with a red background, for example, that would alert the user to the fact they were about to delete a lot of files?

I also wondered about whether there need to be guards against deleting running notebooks?

[takluyver]

I wonder about having a single button that is Shutdown if any selected items are running notebooks, and Delete otherwise (the label/icon would change, not just the action). That way it takes two clicks to delete things including a running notebook, and it's clear what they're doing.

[psychemedia]

Something I just noticed - if I tick a selection of running notebooks to shut them down, when I click on shutdown the notebooks remain ticked. I half expect the ticks to be removed by the action? eg if I'm going to shutdown notebooks and then delete some of them, I currently need to:

• select notebooks I want to shutdown,
• shut them down,
• untick them,
• select the notebooks I want to delete,
• delete them.

As compared to:

• select notebooks I want to shutdown,
• shut them down (and automatically untick them),
• select the notebooks I want to delete,
• delete them.

I know the overhead of unticking all is trivial, but I still feel like it's too easy to select notebooks and in-haste delete them (I'm forever trying to make reminder prompts disappear quickly and can - in haste - take the wrong option without paying due heed to the prompt...!;-)

[donaldbraman]

I think the best way to deal with this is via full git integration. Then you have full suite of git-related versioning tools to help you deal with accidental loss of code: just revert! See, e.g., this gist. No reason to solve this long-standing coding problem again. Just posted another feature request about this.

[takluyver]

As useful as git is, I don't think that's the answer we need here. IPython shouldn't rely on git being installed, and it would be hard to build a UI around git that is intuitive for novice users. For instance, what if you have changed other notebooks in the repository since deleting the one you now want to recover? Just reverting doesn't help there.

Also, we're often curating notebooks in repositories manually, and if every save was a new commit to that repository, automated commits with trivial commit messages would quickly take over the history. If you were playing around with plots or other images in notebooks and saving frequently, it would also make the repository balloon in size.

There are really interesting possibilities with using git as a storage backend for notebooks, and that was one of the cases we had in mind when we made the contents manager & the checkpoint manager APIs that other people can implement. But I don't think it's going to become the default way to run the notebook, and I think we need a solution to this that doesn't rely on it.

[donaldbraman]

Makes sense. (I still love the idea of a more robust git integration for other purposes.)

[takluyver]

So do I ;-).

@jdfreder @ssanderson - we were going to make some documentation of custom content managers, I think. Has that been started yet? We could sprint on it at SciPy if you like.

[ssanderson]

@takluyver I was waiting on the docs infrastructure to settle down before starting on those docs. Are they in a place that's ready for external hands?

@donaldbraman you might also be interested in https://github.com/csiro-scientific-computing/GitCheckpoints and https://github.com/csiro-scientific-computing/NotebookDiff, which implement the Checkpoints API in terms of git commits and adds diffing functionality to the notebook using git diff as the backend.

[takluyver]

I think so, but check in with @jdfreder, who was co-ordinating the notebook docs.

Oh cool, I didn't know about those two projects.

[donaldbraman]

@ssanderson those are very cool. Will definitely check them out.

[Carreau]

We really need a place where people can register that. Like a wiki extensions page.

The keeping things ticks is (IIRC) a design decision from @ellisonbg .

[jdfreder]

@ssanderson yeah, the docs stuff is mostly settled now.

[ssanderson]

@donaldbraman I also maintain a relatively mature contents extension here: https://github.com/quantopian/pgcontents.

@jdfreder great! Can you point me at where I'd go to make changes/additions?

[jdfreder]

@ssanderson you should probably write the content as an RST document for now. Place the new file in ./docs/source . Then add a reference to it in the index.rst, in that same folder. You can then test your document by running make html in ./docs, which will produce an HTML build of the docs, IIRC in ./docs/build. Once your content is merged, it will appear on http://jupyter-notebook.rtfd.org/ .

If you're interested in writing the docs as a notebook instead, let me know, the steps are slightly different.

[nikolayvoronchikhin]

Hi, it would be great as an enhancement to a future version of Jupyter. In the Jupyter Notebook UI, the check boxes should get reset after any action. This way, you don't accidentally delete a notebook.

[JamiesHQ]

Added to 5.1 milestone based on @takluyver 's comment in https://github.com/jupyter/notebook/pull/1968

[takluyver]

I'm trying to get to 5.1 and we're basically no closer to solving this. Like #1968, I'm bumping it to backlog.