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

Read-only mode not functioning as expected in jupyter collaboration #324

Open
Meriem-BenIsmail opened this issue Jul 10, 2024 · 7 comments
Labels
bug Something isn't working

Comments

@Meriem-BenIsmail
Copy link
Contributor

When opening a shared notebook that has read-only permissions, the notebook does not behave as expected.

I was able to modify the notebook, and when I pressed Ctrl + S to save the changes, the modifications were saved instead of being restricted. Additionally, this action resulted in a 500 Internal Server Error.

    PermissionError: [Errno 13] Permission denied: '/home/meriembenismail/Documents/timeline/jupyter-collaboration/.ipynb_checkpoints/Untitled1-checkpoint.ipynb'

The expected behavior is that the notebook should be unchangeable when set to read-only, and any attempt to save changes should be prevented without causing errors.

  • The actual behavior of a read-only notebook in jupyter collaboration : with the RTC prefix
    readonlyRTCNotebook

  • This is how it is without the RTC prefix
    readonlyNotebook

@Meriem-BenIsmail Meriem-BenIsmail added the bug Something isn't working label Jul 10, 2024
@davidbrochart
Copy link
Collaborator

Thanks @Meriem-BenIsmail for looking into this.

I think we need to clarify what we mean by read-only documents:

  • in non-RTC mode, this currently means that users cannot save to disk, but they are still able to modify the document in the frontend.
  • in RTC mode, it is not enough to not save the document to disk, because changes made in the frontend are synced with the backend and with other peers.

Thus we need a read-only mode where:

  • ideally, JupyterLab doesn't allow to change the document (type into a cell, create new cells, etc.).
  • or, changes made in the frontend are not sent to the backend.
  • at least, changes received by the backend from a user who has a read-only document are discarded.

@krassowski
Copy link
Member

ideally, JupyterLab doesn't allow to change the document (type into a cell, create new cells, etc.).

I do not agree. The design principle with most document editors is that when file is not writable user is still allowed to edit it and save to a different file. The reason why the warnings are not showing up in UI is because the collaborative model does not share the information about file being read-only with the frontend.

@davidbrochart
Copy link
Collaborator

The design principle with most document editors is that when file is not writable user is still allowed to edit it and save to a different file.

That's fine in a non-collaborative mode, but in collaborative mode users can have different permissions. On user could have rights to modify a document and another user could only be allowed to view the document. Letting the UI modify the document for the latter, and preventing their changes to be applied to the shared document, will lead to a broken state, right?

@krassowski
Copy link
Member

Does the collaborative mode as of today has a notion of different permissions? It would seem to me that if file is read-only for the jupyter-server user then it is read-only no matter which jupyter user is connecting to the server.

@davidbrochart
Copy link
Collaborator

Permissions are at the Jupyter server API level, and jupyter-collaboration uses WebSockets so it could use this information. But we are talking about different things here, filesystem permissions vs user permissions.
Anyway, if the UI accepts changes this is already too late, the documents have diverged and the (read-only) user won't be able to follow the document changes (made by other users) anymore.

@Meriem-BenIsmail
Copy link
Contributor Author

I’m actually building a timeline slider in jupyter collaboration and while the user is sliding through the timeline, I want to prevent them from editing the document. The behavior I'm aiming for is similar to the history feature in Google Docs, as demonstrated in this GIF.

googleDoc-readOnly

@davidbrochart
Copy link
Collaborator

I'm thinking that as soon as the user changes the document while navigating the history, this should create another fork of the (forked) document, but this time from the current state of the fork instead of from the head of the root document. In other words, we should keep on forking forks, and that corresponds to a new branch each time. This way we don't need the document to be read-only.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants