Peers marked as read-only can use keyboard shortcuts to edit and cause inconsistencies. Examples include: Ctrl-D (Delete line), Ctrl-Up/Down,
Ctrl-Alt-Up/Down
The result of the release test:
Basically it works. However, for pasting the result is not ideal. When
pasting the changes are only visible locally and the user does not get a
read-only warning but an inconsistency error. As no changes from the
write-restricted user are transfered, this behaviour is only inconvenient not critical.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't get it: What is "for pasting the result is not ideal" supposed to mean?
What exactly did you do as a read-only participant to circumvent the newly implemented "barrier" (see commit [2f555d]).
Last edit: tobous 2018-03-23
Even Eclipse has some limitations. Last but not least you can modify the file outside of the Eclipse IDE.
Last edit: tobous 2018-03-23
The result of the release test:
Basically it works. However, for pasting the result is not ideal. When
pasting the changes are only visible locally and the user does not get a
read-only warning but an inconsistency error. As no changes from the
write-restricted user are transfered, this behaviour is only inconvenient not critical.
I don't get it: What is "for pasting the result is not ideal" supposed to mean?
What exactly did you do as a read-only participant to circumvent the newly implemented "barrier" (see commit [2f555d]).
Related
Commit: [2f555d]
A description would be nice indeed. What still works are shortcuts like copy/cut/paste.
So the question is: does invoking those shortcuts also unlock the locked actions again ?