| Title | Can't fix job owned by user (None) in the TeamTrack integration |
| Status | closed |
| Priority | critical |
| Assigned user | Gareth Rees |
| Organization | Perforce |
| Description | If an issue has no owner in TeamTrack (and therefore the owner of the corresponding job is (None) in Perforce) then you can't transition the job by fixing it. The replicator is unable to replicate the change to the job and it overwrites the job with the issue. |
| Analysis | This has the same underlying cause as job000016, job000042, job000086 and job000133. The reason that the replicator can't replicate the job is that it can't tell who last modified it, so it can't suggest a user on whose behalf to do the transition in TeamTrack. The last modifier was the person who made the fix, but Perforce didn't update the "always" fields in the job (only its state field), so there's no record of the modifier. In this circumstance the replicator falls back on the owner of the job as the user on whose behalf to do the transition (to fix job000133), but in this case there's no owner, so this fails. The best solution would be for Perforce to update the "always" fields in the job when someone makes a fix against the job. We could work round this as follows. When the replicator is trying to work out who last modified the issue, it looks in the P4DTI-user field; if that's not helpful, it looks in the Owner field. I suggest that before looking at the Owner field the replicator look at all the fixes for the job. If there are any fixes modified after the job's modification date, use the person who made the latest fix as the job modifier. Otherwise, use the Owner. GDR 2001-02-23. This workaround still won't do the right thing in all circumstances. For example, suppose someone fixes a job and then deletes the fix before the replicator manages to replicate it. In this case the job status has changed, but there's no record in Perforce of who changed it. I submitted this problem as job000276, but that job is only optional. GDR 2001-02-23. This is Perforce's job 5207. |
| How found | customer |
| Evidence | <http://info.ravenbrook.com/mail/2001/03/22/00-21-00/0.txt>See < http://info.ravenbrook.com/mail/2001/03/23/22-48-22/0.txt> for TeamShare's perspective. |
| Observed in | 1.0.5 |
| Introduced in | 0.4.1 |
| Created by | Gareth Rees |
| Created on | 2001-03-22 07:38:32 |
| Last modified by | Gareth Rees |
| Last modified on | 2001-12-10 19:34:37 |
| History | 2001-03-22 GDR Created. 2001-03-23 GDR Changed priority to "critical" since Perforce have given it severity A. Added workaround proposal to analysis. 2001-03-27 RB Added link to TeamShare's opinion. |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 10466 | closed | 2001-03-23 08:24:24 | Gareth Rees | Fixed the job_modifier() method to deal with the difference in date formats between jobs (where a $date looks like '2000-12-31 23:59:59') and fixes (where the Date field is a string who integer conversion gives the number of seconds since 1970-01-01 00:00:00). |
| 10465 | open | 2001-03-23 08:06:05 | Gareth Rees | New method job_modifier() in replicator.py makes a best guess at who last modified the job, by considering (1) the user who made the most recent fix (if any made since the job was last modified); (2) the user in the P4DTI-user field of the job (if that's not the replicator); (3) the owner of the job. |