Record changes in text document can be bypassed by the context menu of a changed text Step to reproduce Take an empty text document, fill with dummey text. Activate Edit - Changes - Record Activate File - Properties - Security - Record changes ang give a password Save file, close file Open file Type anything, changes are recorded place cursor in changed text Context menu - Accept /reject is hot and live. Desired results; Accespt / Reject should not be active.
Gosh, a feature I never used yet :-) The semantics are to allow another commenter to add/change stuff, but not to be able to remove existing red-lining ? if so I see what's up :-) I imagine this is down to the new: FN_REDLINE_ACCEPT_DIRECT etc. items that were added to make this more ergonomic not having the right sensitivity. I guess that this code: sw/source/ui/uiview/viewstat.cxx (GetState) case FN_REDLINE_ACCEPT_DIRECT: case FN_REDLINE_REJECT_DIRECT: { SwContentAtPos aCntntAtPos( SwContentAtPos::SW_REDLINE ); Point aCrsrPos = pWrtShell->GetCrsrDocPos( sal_True ); if( !pWrtShell->GetContentAtPos( aCrsrPos, aCntntAtPos ) ) rSet.DisableItem( nWhich ); } Is simply not powerful enough to notice and adapt to this change-track password-protection, and that some code from the existing changes accept/reject logic needs inserting into there. Turn into an easy-hack.
I'm trying to fix this. Since this is my first one, I'm not sure that I can do it, let me try anyway.
Deleted "Easyhack" from summary.
As this problem has been untouch for a long time, I will try to have a look at this one for my first one
http://cgit.freedesktop.org/libreoffice/core/commit/?id=1fb69ba27999606db68915fe745629b2ed42c8b1
*** Bug 50807 has been marked as a duplicate of this bug. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.