Read-only mode not functioning as expected in jupyter collaboration

[Meriem-BenIsmail]

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
  

• This is how it is without the RTC prefix
  

[davidbrochart]

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]

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]

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]

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]

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]

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.

[davidbrochart]

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.