https://bugs.documentfoundation.org/show_bug.cgi?id=167194
Lars Jødal <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Version|26.2.0.0 alpha0+ master |25.8.0.0 alpha0+ CC| |[email protected] Status|UNCONFIRMED |NEW --- Comment #3 from Lars Jødal <[email protected]> --- 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. -- You are receiving this mail because: You are the assignee for the bug.
