Community
Participate
Working Groups
If the offline file is replace with an version that has the data for a particular bug but is old (and user has read before), upon opening in the editor the subsequent sync will result in new incoming changes (although they've been read before). The reason for this is that upon loading and displaying the old task in the editor, the editor calls RepositorySynchronizationManager.setTaskRead() which set the last read date to the timestamp on the (old) task data. The fix is to do do an actual date comparison so ensure that setTaskRead() doesn't set the date if the date held in the AbstractRepositoryTask is more recent than the date offered by the task data. This will result in the 'new' incoming changes highlighted upon opening but will not cause incoming status on the task. Rather than hard code date comparison of this field we should likely get a comparator from the respective connector or add a method...
Since this is an edge case and it is getting late in the 2.0 game, I'm deferring to 3.0.
New API has been added to AbstractRepositoryConnector for determining if task data that is received from the repository has changes: public boolean hasChanged(AbstractTask task, TaskData taskData); Connector may now implement a policy that is based on comparing dates (e.g. JIRA uses the last modification date) rather than strings.
