| Title | Fields may change even when replication fails |
| Status | closed |
| Priority | critical |
| Assigned user | Gareth Rees |
| Product | project |
| Organization | Ravenbrook |
| Description | If replication to TeamTrack fails after some fields have been converted, those fields will be updated anyway, despite the replication failing. |
| Analysis | This happens because the converted fields are changed in the case object. This same case object is used in the call to update_action, which has the side effect of replicated (some of) the fields as well as setting the action. |
| How found | manual_test |
| Evidence | From the logs during testing of release 0.3.2: 2000-10-18 15:17:09 UTC P4DTI-00 case 1 job has changed 2000-10-18 15:17:09 UTC P4DTI-00 case Replicating job 'case_BUG00017' to issue '18' 2000-10-18 15:17:10 UTC P4DTI-00 case -- Added filespec //depot/project/foom/white.css 2000-10-18 15:17:10 UTC P4DTI-00 case Issue '18' conflicts with corresponding job 'case_BUG00017'. An error occurred while trying to replicate. Traceback (innermost last): File "replicator.py", line 747, in replicate_many self.replicate(issue, job, status) File "replicator.py", line 848, in replicate return self.replicate_job_to_issue(job, issue) File "replicator.py", line 960, in replicate_job_to_issue filespec_diffs) File "dt_teamtrack.py", line 166, in transform_from_job userid = self.dt.transform_user_p4_to_dt(job['P4DTI-user']) File "dt_teamtrack.py", line 690, in transform_user_p4_to_dt raise error, ("No TeamShare user corresponding to " P4DTI TeamTrack interface error: No TeamShare user corresponding to Perforce user 'rb' |
| Observed in | 0.3.2 |
| Created by | Richard Brooksby |
| Created on | 2000-10-18 16:24:57 |
| Last modified by | Gareth Rees |
| Last modified on | 2001-12-10 18:57:48 |
| History | 2000-10-18 GDR Created during testing of release 0.3.2. |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 3822 | closed | 2000-10-27 21:47:11 | Gareth Rees | When updating the action fields of the issue and job when the replicator discovers a conflict, it make sure it updates the issue/job as found in the database and not the copy it has in hand, which may have changed. This is probably not the best fix for this problem, but it's simple and quick for the alpha. |