Description: The interaction of copy and paste with protected cells is very awkward. The ability to copy a protected cell into a protected sheet while the sheet protection is on is important to my users. However, it is surprising that there is only one way to modify the pasted data after doing this -- Undo. If the user does something unintended then saves and re-opens the file, the only way to undo what the program let the user do is unprotect the sheet which the user may not be allowed to do. See Expected Results for a suggestion on how to improve this without restricting the user. Steps to Reproduce: 1. Create a new Calc sheet. 2. Put arbitrary data into cell A1. 3. Set cell B1 as NOT Protected through Format Cells > Cell Protection. 4. Tools > Protect Sheet with the default options. 5. Select cell A1 and copy it with Ctrl+C. 3. Select cell B1 and press Ctrl+V to paste. 5. Press Delete to attempt to clear B1. Actual Results: The clear of B1 using Delete (as well as by text edit, etc.) is blocked because the protection of cell A1 was copied to B1. Expected Results: Suggest that when the destination sheet protection is ON, any pasted cell should automatically be unprotected as part of the paste operation. To see that the user has the right to do this, this is equivalent to copying the protected cell to a new unprotected sheet, clearing the protection there, and then using copy/paste from the new sheet to the protected sheet. When the destination sheet protection is OFF, the current behavior to copy and paste the protected state makes sense. Reproducible: Always User Profile Reset: No Additional Info: Version: 6.2.1.2 (x64) Build ID: 7bcb35dc3024a62dea0caee87020152d1ee96e71 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: CL
(In reply to jasonkres from comment #0) > The clear of B1 using Delete (as well as by text edit, etc.) is blocked > because the protection of cell A1 was copied to B1. i can confirm this behaviour current workaround: use paste special > Expected Results: > Suggest that when the destination sheet protection is ON, any pasted cell > should automatically be unprotected as part of the paste operation. > To see that the user has the right to do this, this is equivalent to copying > the protected cell to a new unprotected sheet, clearing the protection > there, and then using copy/paste from the new sheet to the protected sheet. this seems to be the same as ms excel 2016 does. makes sense for me.
Created attachment 149857 [details] demo copy cell protected_sheet
Created attachment 149858 [details] demo copy cell protected sheet (xlsx)
You set cell protection first via Edit > Cell Protection (applied to selection, on by default) and enable it subsequently per Tools > Protect Sheet... Admittedly a bit weird but the function itself is working well. Learn more at https://help.libreoffice.org/6.2/en-US/text/scalc/guide/cell_protect.html?DbPAR=CALC#bm_id3146119
(In reply to Heiko Tietze from comment #4) > You set cell protection first via Edit > Cell Protection (applied to > selection, on by default) and enable it subsequently per Tools > Protect > Sheet... Admittedly a bit weird but the function itself is working well. i know, but the way excel does it in case of copy and paste protected cells into an unprotected area (while the sheet is protected) is much more intuitiv, cause the user is able to edit the copied range later.
(In reply to Oliver Brinzing from comment #5) > ...the way excel does it in case of copy and paste protected cells > into an unprotected area (while the sheet is protected) is much more > intuitiv, So the request changes to become more Excel-like? Sounds like a safety issue but please elaborate a bit.
FYI, here's the actual case that led to this: 1. User is working on a sheet that is protected. 2. User sees a value in a protected cell that they would like to "reuse" in an unprotected cell -- including formatting, perhaps with some minor additional edits to the data. 3. So they Copy the protected cell and Paste it to an unprotected cell. At this point, the paste succeeds and it looks good onscreen. 4. But the user then finds unexpectedly that they cannot further edit (or even Delete) the destination because it has switched to be a protected cell. (Their option at this point is to Undo.) The reason it is unexpected from the user's point of view is that they think the cell is one that are supposed to be allowed to edit, and they are surprised that they were able to alter protection of the cell from unprotected to protected even though the sheet is currently "locked".
(In reply to jasonkres from comment #7) > FYI, here's the actual case that led to this... So you expect the protection flag to not get copied when I paste into unprotected cells. Sounds reasonable but OTOH users might expect the number itself to be protected. What do you think, Eike?
(In reply to Heiko Tietze from comment #8) > (In reply to jasonkres from comment #7) > > FYI, here's the actual case that led to this... > > So you expect the protection flag to not get copied when I paste into > unprotected cells. Sounds reasonable but OTOH users might expect the number > itself to be protected. What do you think, Eike? @Eike, any opinion here ?
At first sight sounds reasonable. But then again, if a protected cell is copied to (or within) a temporarily unprotected sheet and that sheet then is protected again, isn't the cell expected to be protected? I guess whatever we do it will be odd for some users in some cases. So, removing the protected state only if a) the sheet is protected, and b) the target cell is unprotected looks sensible to me.
(In reply to Eike Rathke from comment #10) > So, removing the protected state only if > a) the sheet is protected, and > b) the target cell is unprotected > looks sensible to me. Great, let's do it then.
(In reply to Heiko Tietze from comment #11) > (In reply to Eike Rathke from comment #10) > > So, removing the protected state only if > > a) the sheet is protected, and > > b) the target cell is unprotected > > looks sensible to me. > > Great, let's do it then. +1 as long as it only works with ui copy & paste. IMO the copyRange() API method should not change cell attributes.
*** Bug 132829 has been marked as a duplicate of this bug. ***
Note that this bug and bug 150910 somewhat contradict each other in expectations.
*** Bug 150910 has been marked as a duplicate of this bug. ***