https://bugs.documentfoundation.org/show_bug.cgi?id=166723
--- Comment #31 from Lars Jødal <[email protected]> --- (In reply to Tuomas Hietala from comment #29) > (In reply to Eyal Rozenberg from comment #21) > > Remember: "Rejection" or "Acceptance" of changes are actions which vanishes > > a proposed ("tracked") change. If the change is accepted - the underlying, > > untracked, document changes; if the change is rejected - the underlying > > document does not change. > > I would guess this ("Reject and Accept both make the proposed change vanish, > so they're closely related") is the way users typically think about change > tracking. Well, as a (typical?) user, I think of Reject and Accept in this way: Reject: No, I do not want the change, make the underlying document go back to what it was, i.e., the resulting document should be unchanged compared to the baseline document. Accept: Yes, I want the change, incorporate it into the underlying document, i.e., the resulting document be changed from the baseline. In both cases: The document is of course changed in relation to "baseline with tracked changed", and the tracked change (with some representation under the hood) is removed as a tracked change, so the current document will have one less tracked change. As I understand the idea behind, and use of, Reinstate, it is to be used when one would otherwise use Reject, but wants it to be seen, what was suggested. I can see that under the hood, this must call for quite different code than simply removing the suggested change. As a user, I think of it as "reject the suggested change, but leave a track of what was suggested". Like this: Reinstate (or what term we end up with): No, I do not want the change, but I want the document with change-tracking to reflect my action (which a simple Rejct will not do). The document is changed from baseline, but in a way such that if I afterwards Accept all changes, then I am back to baseline. > > The action we're discussing is an _acceptance_, not a _rejection_. After the > > acceptance, a reversion is introduced as a tracked change. > > I suppose "Accept, then revert" the would then be the most technically > correct description for what happens 'under the hood'. But I don't think it > would make sense for the average user who is not a developer or LO > power-user. Trying to understand: In what way is Reinstante an acceptance? Do you mean "acceptance" in the sense that the change still is part of the text (even though it involves text tracked as deleted)? Or...? Whereever this lands, hopefully it will be in a place that makes sense to the average/typical user (and hopefully without being horrible to look at for the developer). As a user, I would like to way thank you for developing a very useful feature. Please decide for a name that makes it understandable for me what it is useful for, also if I had not been part of this thread. -- You are receiving this mail because: You are the assignee for the bug.
