With a recent 26.2 nightly, do the following: 1. Create a new Writer document 2. Enable 'Track Changes' 3. Type "hello" 4. Right-click the word you typed 5. Choose "Reinstate" / "Reject but track" Expected results: ??? Actual results: The change is rejected, the word is deleted, and the document is empty. I don't think that makes sense. Rather, this action should probably be _disabled_ for a user's own changes. They can reject them, they can accept them, but it's senseless for the same user to both propose a change and propose to revert it.
This is probably not intentional. By default Writer tries to combine your changes, so e.g. not every typed character is a new redline. This goes too far here and your own insert + delete on top of it is combined, and probably should not. This may be the the same as bug 166790
*** Bug 166790 has been marked as a duplicate of this bug. ***
The described behaviour is confirmed, and is present already at the feature's introduction in 25.8. I have not seen the code for implementation of "Reinstate" / "Reject but track", but the effect may be described as writing deletion (of inserted text) or insertion (of deleted text) on top of the change. This works very well when the original change is made by one user and "Reinstate" / "Reject but track" is made by another user. However, when it is the same user, writing a delete on top of an insertion, the result will be that the text is gone - which fits the observed behaviour. As suggested in the original report, a solution could be to disable the feature for a user's own change, as the feature was never intended for handling your own changes. A side effect of that solution will be that the "Reinstate" / "Reject but track" will be that if a user does not write user name in LO, and the text is handled by another user not writing user name, it will appear like the same user, and the feature cannot be used. This may be acceptable - track changes in any case works best, if user data (name) are available.
(In reply to Lars Jødal from comment #3) > As suggested in the original report, a solution could be to disable the > feature for a user's own change, as the feature was never intended for > handling your own changes. True. However it's makes life rather inconvenient for QA/testing purposes. If you have to switch user to test. I ask myself: is there a downside by allowing to reject but track for your own change?
(In reply to Telesto from comment #4) > (In reply to Lars Jødal from comment #3) > > As suggested in the original report, a solution could be to disable the > > feature for a user's own change, as the feature was never intended for > > handling your own changes. > > True. However it's makes life rather inconvenient for QA/testing purposes. > If you have to switch user to test. Agreed. The problem is that the behaviour differs between the two situations: a) One user makes the change, another user uses "Reject but Track". b) The same user (user name) makes the change and uses "Reject but Track". The feature is intended for situation a). If it is tested in situation b), test results can be confusing. So _not_ disabling the feature in situation b) can also make life inconvenient for testing. > I ask myself: is there a downside by allowing to reject but track for your > own change? For normal users, the downside is the risk of confusion when "Reject but Track" is used upon your own insertion: The change simply disappears, so "Reject but Track" in this special case produces the same result as normal "Reject". For testers, the downside is the risk that the test results will be confusing if the tester overlooks the difference in behaviour. Whether these downsides are serious enough to warrant disabling the feature is a different question. At least at present, I have no strong opinion on that.
... I meant "disabling the feature IN SITUATION B)". I surely do not think the feature should altogether disatabled.
(In reply to Miklos Vajna from comment #1) > This is probably not intentional. By default Writer tries to combine your > changes, so e.g. not every typed character is a new redline. This goes too > far here and your own insert + delete on top of it is combined, and probably > should not. This may be the the same as bug 166790 I don't think it is too far, I think it's just right. (In reply to Telesto from comment #4) > True. However it's makes life rather inconvenient for QA/testing purposes. > If you have to switch user to test. The QA considerations are of course secondary to actual use of the feature. With that said - it is indeed cumbersome to work with different/multiple author identities, not just for QA. See for example my bug 162423 (and you are encouraged to reopen it); I also just filed bug 167240, although I have a feeling it's a dupe. > I ask myself: is there a downside by allowing to reject but track for your > own change? IMNSHO, the answer is no. Given that there is no real "reject", just propositions of deletions/insertions - I don't believe this makes sense. But - I am open to be convinced otherwise.