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
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:
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
*** Bug 50807 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (EasyHack,DifficultyBeginner,SkillCpp,TopicUI, )