Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Respect 'editable' cell metadata #1482

Merged
merged 5 commits into from
Sep 21, 2016
Merged

Conversation

yuvipanda
Copy link
Contributor

@yuvipanda yuvipanda commented May 24, 2016

  • Readonly cells can not be split or merged or deleted
  • Readonly cells can be executed
  • End users can still modify this by editing the metadata
    themsevles directly

Fixes #1402

- Readonly cells can not be split or merged
- Readonly cells can be executed
- End users can still modify this by editing the metadata
  themsevles directly
@yuvipanda
Copy link
Contributor Author

Should readonly cells be deletable? I'm unsure! Perhaps it's ok to keep those two orthogonal, but might be confusing?

Should it provide some other visual indicator of being readonly? Probably, although I'm not sure what form that should take.

TODO:

  1. Add tests
  2. Figure out if setting codemirror option on every focus has performance penalties, or if there is a better location to put that in.

I haven't really written any client side JS in a few years, so be gentle!

@takluyver
Copy link
Member

From a UI point of view, I'd expect readonly cells to also be undeletable; it's hard to imagine a scenario where you want a non-editable but deletable cell.

@@ -171,6 +171,8 @@ define([
if (that.keyboard_manager) {
that.keyboard_manager.enable();
}

that.code_mirror.setOption('readOnly', that.is_readonly());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is on code cells - do we want non-editable Markdown & raw cells as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I've duplicated it in textcell.js, which seems to be the only other cell type defined? I can't really set this in the parent cell.js since no codemirror stuff happens there.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's MarkdownCell and RawCell, both in textcell.js, but TextCell is the parent class, so if setting it there works, that's good.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, just did :)

@takluyver
Copy link
Member

Will it be awkward that the two protection options work opposite ways round - deletable: false but readonly: true? Do we want editable: false instead?

@yuvipanda
Copy link
Contributor Author

In general I prefer defaults to false than defaults to true, but since it is already 'deletable: false' rather than 'undeletable: true', I guess it makes sense to keep it consistent.

While I prefer things that default to false than true,
in this case it is better to be consistent with is_deletable
@yuvipanda yuvipanda changed the title Respect 'readonly' cell metadata Respect 'editable' cell metadata May 24, 2016
@Carreau
Copy link
Member

Carreau commented Jun 4, 2016

I'm fine with changing the default, be warned that @jhamrick nbgrader might need to be updated as, IIRC, it is the main usecase.

@yuvipanda
Copy link
Contributor Author

Yeah, I think this just needs tests. I'll try to pull in some time next
week to finish this up.

On Fri, Jun 3, 2016 at 5:17 PM, Matthias Bussonnier <
notifications@github.com> wrote:

I'm fine with changing the default, be warned that @jhamrick
https://github.com/jhamrick nbgrader might need to be updated as, IIRC,
it is the main usecase.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1482 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAB23qN_GylSQWIh-WGm5rjLOJwi2ICLks5qIMQBgaJpZM4IlKSo
.

Yuvi Panda T
http://yuvi.in/blog

@jhamrick
Copy link
Member

jhamrick commented Jun 4, 2016

I think not editable should imply not deletable as well.

I'm fine with changing the default but if we do that (go from deletable to undeletable) could we build in something that would automatically update the notebook metadata if the old deletable metadata is found?

Also thanks @yuvipanda for implementing this!!

@minrk
Copy link
Member

minrk commented Jun 6, 2016

Yup, any change like that should include automatic upgrading of the old format on load.

@Carreau Carreau added this to the 5.0 milestone Jul 29, 2016
@gnestor
Copy link
Contributor

gnestor commented Aug 18, 2016

@minrk I can work on this. To make sure I understand: if the deletable property is not available for a cell in a notebook, then we should provide a value for it depending on the cell's editable property (e.g. if metadata.editable = false then metadata.deletable = false, otherwise metadata.deletable = true).

@gnestor gnestor self-assigned this Aug 18, 2016
@minrk
Copy link
Member

minrk commented Aug 23, 2016

@gnestor I believe that's correct, yes.

* @method is_deletable
**/
Cell.prototype.is_deletable = function () {
if (this.metadata.deletable === false) {
if (this.metadata.deletable === false || !this.is_editable()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with changing the default but if we do that (go from deletable to undeletable) could we build in something that would automatically update the notebook metadata if the old deletable metadata is found?

@jhamrick This block will handle cases where metadata.deletable is undefined (is_deletable() will return true). Do you think that we need to write that value back to the metadata? It seems like this would only be necessary if a notebook were to be used in another client that doesn't define an is_deletable() equivalent.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think it should update the old metadata. As @minrk said:

Yup, any change like that should include automatic upgrading of the old format on load.

So even before it gets to the point of checking if the cell is deleteable, ideally the old metadata format should be updated.

@gnestor
Copy link
Contributor

gnestor commented Sep 12, 2016

@yuvipanda Can you enable "Allow edits from maintainers" for this PR? It's a new Github feature and should be available in the right side bar for this PR.

@yuvipanda
Copy link
Contributor Author

Done! Sorry I haven't had time to finish this up.

@gnestor gnestor closed this Sep 12, 2016
@gnestor gnestor deleted the readonly-cells branch September 12, 2016 18:43
@gnestor
Copy link
Contributor

gnestor commented Sep 12, 2016

@yuvipanda Sorry but I accidentally deleted your branch and I don't think I can restore it on your behalf. I think a git reflog should do the trick. If you can't figure it out either, then I can create a new PR...

@yuvipanda yuvipanda restored the readonly-cells branch September 12, 2016 19:17
@yuvipanda
Copy link
Contributor Author

I've restored it :)

@gnestor
Copy link
Contributor

gnestor commented Sep 14, 2016

@yuvipanda I think the "Allow edits from maintainers" permissions were reset after I deleted your branch. I submitted a PR to your fork that will upgrade a notebook's metadata on load to include editable and deletable properties. Can you merge pleeez?

@yuvipanda yuvipanda reopened this Sep 14, 2016
Upgrade cell's `editable` and `deletable` metadata if not defined
@yuvipanda
Copy link
Contributor Author

Merged and re-enabled!

@gnestor
Copy link
Contributor

gnestor commented Sep 14, 2016

@Carreau Can you test this? I have tested and verified that cell metadata will include editable and deletable properties.

To test:

  1. Create a new notebook or open an existing notebook
  2. Inspect notebook in a text editor, there should be no editable or deletable properties for cells
  3. Save and Checkpoint
  4. Inspect notebook in a text editor, there should be editable or deletable properties for cells

@Carreau
Copy link
Member

Carreau commented Sep 21, 2016

LGTM ! Thanks all !

@jhamrick
Copy link
Member

Would it be possible to include this for the next release (4.4) rather than 5.0? This is a really important feature for nbgrader to have that I thought would have ended up in the 4.3 release, but apparently it didn't. It would be unfortunate if all the instructors waiting on this feature have to wait until 5.0 for it.

@Carreau Carreau modified the milestones: 4.4, 5.0 Jan 13, 2017
@Carreau
Copy link
Member

Carreau commented Jan 13, 2017

let's see how hard it is to backport.

@meeseeksdev backport to 4.x

lumberbot-app bot pushed a commit that referenced this pull request Jan 13, 2017
- Readonly cells can not be split or merged or deleted
- Readonly cells can be executed
- End users can still modify this by editing the metadata
  themsevles directly

Fixes  1402
@Carreau
Copy link
Member

Carreau commented Jan 13, 2017

See #1482.

@Carreau
Copy link
Member

Carreau commented Jan 13, 2017

I mean #2039

@jhamrick
Copy link
Member

Thanks! 😄

@Carreau
Copy link
Member

Carreau commented Jan 13, 2017

Thanks! 😄

No problem. Also I whitelisted you so you can mention the bot to do backport or other stuff.

Carreau added a commit that referenced this pull request Jan 14, 2017
@gnestor
Copy link
Contributor

gnestor commented Jan 31, 2017

Can we release this in 4.3.2? It's currently in 4.x branch and we're about to do a 4.3.2 release...

@minrk minrk modified the milestones: 4.3.2, 4.4 Jan 31, 2017
@minrk
Copy link
Member

minrk commented Jan 31, 2017

I think it's fine. I relabeled it as 4.3.2, since it's already been backported.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

True read-only cells
6 participants