|Title||You can't close a job by fixing it|
|Assigned user||Gareth Rees|
|Description||You can close a job by editing the job and changing the state, but you can't close a job by fixing it. TeamTrack refuses to replicate the fix, and the replicator reopens the job.|
|Analysis||This has the same underlying cause as job000016, job000042 and job000086.|
This is because when you fix a job, the P4DTI-user field doesn't get updated. So if you fix a job and P4DTI-user is the replicator, then the replicator tries to transition the job on behalf of itself; since it doesn't have permission, then it fails. This used to work by coincidence because the replicator was a member of the Administrator group, and could transition all jobs, but we've tightened that up (see job000086).
The best solution would be for Perforce to fix job000016.
One possible workaround would be to restore the replicator's privileges so that it can always do a transition. A second workaround would be to use the Owner field to do the transition when the P4DTI-user field is the replicator. In either case, people will be able to make transitions that they don't have permission to do (so job000086 is increased in severity).
I recommend using the Owner field as a workaround. It's best that the replicator has fewer privileges, as that is likely to introduce more obscure security holes, and it would make configuring TeamTrack more complicated. RB 2000-12-06
|Evidence||Observed in 0.4.0.|
|Created by||Gareth Rees|
|Created on||2000-12-06 12:00:06|
|Last modified by||Gareth Rees|
|Last modified on||2001-12-10 19:12:09|
|History||2000-12-06 GDR Created.|
|5535||closed||2000-12-06 13:28:29||Gareth Rees||Fixing job000133 (replicator gets wrong user when a job is fixed):
Report both the user and the transition when a transition is generated, to make this problem easier to spot and debug if it happens again.
When the last person who changed the job is the replicator user, update the issue on behalf of the job owner instead.