Open filbertphang opened 1 year ago
Background: We implemented undo/redo as stated in DG which is using list of history of client book (address book). So there is no record of what specific command the user do. Moreover, it would cause significant memory overhead if we store command history just to show info
Team chose [response.Rejected
]
Reason for disagreement: - The rationale provided only explains why this feature is not currently implemented, and not why this feature SHOULD NOT be implemented. Just because it is implemented in a particular way currently does not mean that it should not be implemented in a different/better way.
Undo: delete 1
). This should require no more than 1 String variable worth of data for each given state.If anything, the rationale provided implies that the team feels like this bug should be classified as "Not in scope", rather than "Rejected".
Upon a successful
undo
/redo
command, the only result provided is "undo success" or "redo success". However, the actual action that was undoed/redoed is not explained, so users do not know what has actually changed.This problem is especially notable when we consider that appointments and policies can also be undoed/redoed, so it is not immediately obvious what change has been undone/redone.