Community
Participate
Working Groups
To reproduce: 1. Open several editors. Doesn't matter if test suites, test jobs or test cases. 2. Make changes to all of them, e.g. edit a comment and save. 3. The changes will appear in the properties view. 4. Execute the "Delete all tracked changes" operation. 5. Go back to the Specification view. 6. The editor which is in foreground will correctly have no tracked changes visible in its properties view because they were deleted. 7. The other editors, which were in background, will still have the old tracked changes visible in their corresponding properties view. Not even making another change causes the properties view to refresh and display the new change. To make the deletion visible it is necessary to switch the selection in the editor and back or reopen the editor. What should be do about that?
If we can make the UI update correctly in this case, that would be good. If we can't make the UI update correctly, would closing all editors be a viable alternative? (We'd have to check whether the read-only properties view is also correctly updated in this case, otherwise we'd have gained little). If we can't make the UI update correctly, and we decide that closing editors is not acceptable, then I could probably live with this behaviour as long as it leads to no errors (i.e. what if change tracking is still activated and a new change is made -> is the new change displayed correctly?). In short, I'd like to see this looked at as a part of the sprint task for deleting the change tracking information. One way or another we should try to get this ticket closed as a part of the deletion story.
On second thoughts, I doubt that closing all editors will be doable since: - other people could have editors open, and we don't want to / can't close them. - editors in the current project might be dirty. What do we do at the moment if an editor is dirty?
Everything is tracked correctly. After making some changes and then reopening the editor all these changes are displayed. This is not the issue.
There don't need to be any tracked changes to make this issue appear. It is sufficient that there is at least one editor in background opened while performing the deletion of all tracked changes. Afterward no changes will be displayed for such nodes until reopening them.
The here described behavior is not caused by the tracking of changes. The tracking makes the more general behavior described in bug 421431 visible. So I mark this as duplicate of said bug. *** This bug has been marked as a duplicate of bug 421431 ***
Closed due to comment 5.
