Steps: 1. open MSO created .DOC with Review-Track Changes-Lock Tracking password "t" Actual in LO 7.0+: opens as read-only (and password "t" doesn't work) Expected: can be edited, Edit-Track Changes-Protect is set with password "t" Previously with LO 6.4.0, .DOC would be also open as read-only but password "t" would unlock editing and Protect could be turned off. That's also not correct, so I don't set regression, but I set bibisectRequest.
Created attachment 160275 [details] Sample DOC
Can't reproduce in: Version: 7.0.0.0.alpha0+ (x64) Build ID: cbe86ee37018dc4bf04783ecf70fef2863e61ad7 CPU szálak: 4; OS: Windows 10.0 Build 17134; Felületmegjelenítés: Skia/Raster; VCL: win; Locale: hu-HU (hu_HU); Felület nyelve: hu-HU Calc: threaded Opens in read-only, but password "t" works, can be edited.
Yes, 7.0+ behaves like before, I don't know how it happened after may tests. Anyway, bug remains. Actual in LO 7.0+: opens as read-only (needs password "t" to edit) Expected: can be edited, password "t" is required only to turn off Edit-Track Changes-Protect
(In reply to Timur from comment #3) > Yes, 7.0+ behaves like before, I don't know how it happened after may tests. > Anyway, bug remains. > > Actual in LO 7.0+: opens as read-only (needs password "t" to edit) > Expected: can be edited, password "t" is required only to turn off > Edit-Track Changes-Protect Confirming this behavior with: Version: 7.0.0.0.alpha0+ (x64) Build ID: 00db5933ded1884b2ac453552badae20fa943478 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; Locale: hu-HU (hu_HU); UI-Language: en-US Calc: CL @Justin I thought You might be interested in this one...
This opens as read-only already in LO 3.5. [Irrelevant information, but...] The ability to use the menu to enter edit mode first came in LO 4.4 commit 2420e776f728aee6171a8afe199ff84907152c39 Author: Joren De Cuyper <on Mon Jul 21 08:25:06 2014 +0000 fdo#80536 UI: Menu entry for 'Edit File' -> 'Edit Mode'
- if (!m_xWDop->fProtEnabled) + if (!m_xWDop->fProtEnabled && !m_xWDop->fLockRev) m_pDocShell->SetModifyPasswordHash(m_xWDop->lKeyProtDoc);
In Word 2003, Lock.doc opens in read-write mode. In Word 2013, it opens in read-only mode. You need to View - Edit document to get started (but of course with no password). So, the question is how far do we want to take this for the DOC format? Currently, when LO round-trips the file, ALL of this information is lost. Laszlo has implemented most of this for DOCX - import and export. But is it worth doing it for the old DOC format? Opening up as read-only (like DOCX) seems very stupid to me, so my recommendation would be to just ignore the password completely in this case (since it is lost anyway) and open in read-write mode (just like sensible Word 2003). Otherwise we also need to map it to the correct document security functions, and export it. That seems like unnecessary effort at this stage in the game. [For completeness, I also looked at the fourth lock option, which allow comments only. I don't think Writer has support for that, so it should be treated the same as a read-only protection - requiring the password to unlock to edit.] In all cases - including read-only, all of the protection is lost just by round-tripping. So if a password is defeating you, just save-as and reload - no password, no protection (except forms, which protects the section, but without a password). Proposed fix (which just ignores LockRev/password) at https://gerrit.libreoffice.org/c/core/+/93551
(In reply to Justin L from comment #7) > In Word 2003, Lock.doc opens in read-write mode. > In Word 2013, it opens in read-only mode. You need to View - Edit document > to get started (but of course with no password). I don't confirm. In Word 2016, it opens in read-write mode. Maybe your read-only is because file is from internet, please resave it. I didn't also understand your explanation. We need Lo to behave as MSO: file is read-write and can be edited, without password, and it keeps Track Changes. Password is needed only to turn off Edit-Track Changes-Protect.
Filesave is another issue, See Also bug 132636.
Created attachment 160422 [details] Lock.screenshot.jpg: What word 2016/2013 look like after opening Lock.doc (In reply to Timur from comment #8) > Maybe your read-only is because file is from internet, please resave it. I copied it to the desktop on both 2013 and 2016 and it still opens in read-only mode. > I didn't also understand your explanation. We need Lo to behave as MSO: > file is read-write Yes > and can be edited, without password, Yes - the password is lost actually. > and it keeps Track Changes. Yes - completely unaffected. >Password is needed only to turn off Edit-Track Changes-Protect. No. So far LO doesn't keep the password for forms or read-only mode either, and after a round-trip, the document is unprotected in Word.
Created attachment 160423 [details] LockC.doc: Word 2003 locked to allow only inserted comments After round-tripping this in LO, the comment protection is lost.
Created attachment 160424 [details] LockR.doc: Word 2003 locked to be read-only. The read-only protection is lost when round-tripped by LO.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0f7f3ede6699df09be5b0d9d24818cf1fbbaf6f6 tdf#132637 doc import: don't open readonly for lockRev It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The issue of actually locking track changes depends on the ability to export it. So this issue is not yet resolved, but at least the document can be used in the meantime. I will not be attempting to do the export or import, so removing myself as the assignee.
Dear Timur, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug