Description Sebastien Dubois 2012-03-14 18:16:26 EDT

The solution for postponed anomalies needs to be improved

Summary of current solution:
* Importing anomalies via a user context option to an open review
* Importing anomalies via a review opening if a peference is set
* The importing of anomalies is based on file name + extension
* Once an imported anomaly is fixed it's marked as fixed in the orginal review
* Once and imported anomaly is fixed it becomes disabled on the imported containers of other reviews and therefore no longer visible

There are some problems with this approach
1) The new code change can not be tracked to a fixing review/change, as the changes were not part of the original review where they were postponed
2) The original anomaly does not have any reference to the place were these were fixed.
3) There is no reference on the disabled anomalies on where this was fixed, not even in the review were they were marked as fixed
4) Statistics of the completed reviews are being changed as postponed anomalies can indirectly become fixed

The proposed behaviour (to be discussed) is as follows
* When an imported anomaly is fixed, it shall save a fixed@ reference text description of the review were this was postponed but the anomaly state shall remain as "POSTPONED"
* The cloned imported anomalies in other reviews shall also store the reference to the actual fixing review
* The state of the fixed imported anomalies shall change to FIXED only in the review where they were decided upon, and this anomalies shall not be disabled.
* Marking anomalies as disabled on other reviews i.e. not on originating and terminating reviews should be done when anomalies are put to a terminal state, as this will make for consistent counters where the number of Postponed - Number of Imported Fixed shall tend to be zero