Description: It seems that protected status only is pasted if the source cells belong to one row. See https://ask.libreoffice.org/t/weird-behavior-when-copying-protected-cells/81586 Steps to Reproduce: 1. Open attached ODS file (A1:D2 unprotected, sheet protected with empty password). 2. Copy C1:E1 and paste in A1 (the same with C2:E2 in A2, and with A3:B3 in A1) 3. Copy C1:E2 and paste in A1 (the same with A3:B4 in A1) Actual Results: After step 2. Protected status is retained. After step 3. Protected status is not retained. Expected Results: After step 3. Protected status is retained. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.7.2 (x64) / LibreOffice Community Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: default; VCL: win Locale: es-MX (es_ES); UI: en-US Calc: CL
Created attachment 182391 [details] Sample file to test with.
Question: a) "(the same with C2:E2 in A2, and with A3:B3 in A1)" means: a1) "after undo"? As an alternative test? or a2) "as next step"? If (a1): Effect is REPRODUCIBLE with Installation of Version: 7.3.3.2 (x64) Build ID: d1d0ea68f081ee2800a922cac8f79445e4603348 CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE | Calc: threaded | ElementaryTheme | My normal User Profile
Still REPRODUCIBLE with Server Installation of Version: 7.5.0.0.alpha0+ Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU-Threads: 4; BS: Windows 6.1 Service Pack 1 Build 7601; UI-Render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL | Auto Colibre Theme | Special devUserProfile (based on my normal one) Already REPRODUCIBLE with Server Installation of Version: 6.0.7.3 (x64) Build-ID dc89aa7a9eabfd848af146d5086077aeed2ae4a5; CPU-Threads: 12; BS: Windows 10.0; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: CL, Special devUserProfile Copy/Paste of protection status completely fails with Server Installation of Version: 4.0.0.3 WIN10 Build-ID 7545bee9c2a0782548772a21bc84a9dcc583b89; Special devUserProfile Copy/Paste of protection status completely fails with ooo 3.2.0 Additional Info: b) I did not find an obvious DUP with query https://bugs.documentfoundation.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=DUPs150910&sharer_id=19321 b1) But may be some are related? For example Bug 123974?
Note that this bug and bug 123974 somewhat contradict each other in expectations.
(In reply to Eike Rathke from comment #4) > Note that this bug and bug 123974 somewhat contradict each other in > expectations. Too bad for this (later) bug then :) Here a difference was finely found between single and multiple row action. But bug 123974 was already confirmed with opposite expectations, so it seems that we cannot have both. *** This bug has been marked as a duplicate of bug 123974 ***
(In reply to Rainer Bielefeld Retired from comment #2) > Question: > a) "(the same with C2:E2 in A2, and with A3:B3 in A1)" means: > a1) "after undo"? As an alternative test? Yes. (In reply to Timur from comment #5) > Here a difference was finely found between single and multiple row action. Yes. That is the point.
(In reply to Eike Rathke from comment #4) > Note that this bug and bug 123974 somewhat contradict each other in > expectations. They do somewhat, but this bug describes a **different behavior**. Bug 123974 describes the default ability to copy protected cell status in a protected sheet (which, to me, is not a bug at all). This bug, however, describes an inconsistent behavior in Calc, wherein *sometimes* it correctly copies cell protection status in a protected sheet, and *sometimes* it does not. Whether it does or not is wholly dependent on if the copied cell range spans more than a single row. The behavior is shown very clearly in the attached .ods file, and is pretty clearly undesirable, because unpredictable (unless you are aware of this bug). I believe this bug should be addressed separately from Bug 123974.
n gibson, thanks for commenting. You are welcome to comment and to add another QA for a review of status. Please do not change the status set by a member of QA team, and that was wrong change, see https://bugs.documentfoundation.org/page.cgi?id=fields.html#bug_status. Note that you didn't write exact expected results, with regard to already defined bug 123974. Please do. *** This bug has been marked as a duplicate of bug 123974 ***
@Timur: I disagree closing this just as a duplicate of bug 123974, it's a different scenario and probably both will have to be considered when fixing any of them, otherwise we may get an incomplete solution. That's exactly why I mentioned the contradicting expectations and a "too bad too late" really doesn't help here. I'm bringing this up to the UX list therefore.
(In reply to Timur from comment #8) > n gibson, thanks for commenting. > Please do not change the status set by a member of QA team, and that was > wrong change, see > https://bugs.documentfoundation.org/page.cgi?id=fields.html#bug_status. > > *** This bug has been marked as a duplicate of bug 123974 *** Apologies for wrong protocol. I'm quite unfamiliar with the process. > Note that you didn't write exact expected results, with regard to already > defined bug 123974. > Please do. Not sure where to add expected results, other than right here, so in case this helps: IN regards to bug 123974, the expected behavior is the same as the current behavior of Calc as described -- in other words, the behavior is not a bug. It requires no correction. IN regards to *this* bug 150910, the expected behavior is that when any cell or cell range is copied, then its protected status is fully retained when it is pasted into another valid cell or cell range regardless of the protection status of the sheet as a whole.
(In reply to Timur from comment #5) > Here a difference was finely found between single and multiple row action. The point is * pasting one protected cell only into an unprotected area makes this cell protected * pasting at least two cells makes the target unprotected + it doesn't matter if one of the cells is unprotected or all are protected * the decision on bug 123974 c10 was to "remove the protected state only if a) the sheet is protected, and b) the target cell is unprotected" And this should apply to multiple selections too. And whether the flag is set or not needs to be decided on a per cell basis.
(In reply to Heiko Tietze from comment #11) > * pasting at least two cells makes the target unprotected > + it doesn't matter if one of the cells is unprotected or all are protected Yes, if both cells are in different rows. No, if both cells are in the same row. A bit more test shows that the problem is the target, not the source. If the source is A1:A3 or A2:A4 (the first cell unprotected, and last protected, see comment #2), it is possible to paste special with [x] Transpose and [x] Format in A1:A3, and the protected status will remain. (version 7.2.7.2)
(In reply to LeroyG from comment #12) > Yes, if both cells are in different rows. > No, if both cells are in the same row. Tested with data arranged in columns.