| Title | Documentation doesn't explain why fixes don't get undone with other changes |
| Status | closed |
| Priority | essential |
| Assigned user | Gareth Rees |
| Organization | Ravenbrook |
| Description | A user can add a fix for a job that they don't have permission to transition or update. The job status gets set back to how it was, but the fix record remains. The documentation doesn't explain why this happens. |
| Analysis | This happens because the replicator replicates fixes before trying to replicate the job. So even though the change to the job may not be allowed, the fix gets replicated. Then the replicator discovers that the change to job is disallowed, so it replicates back. But the fix went through so it doesn't get deleted. The severity would be reduced if we replicated the job before the fixes. Then we'd discover that the job couldn't be replicated before we replicated the fixes. So the disallowed fix would be deleted when the replicator replicated back. However, this wouldn't completely solve the problem. A user could still fix a job *to the same status* without permission. The replication of the job would succeed (because there would be nothing to do) and so would the replication of the fix. This problem has similar symptoms to job000086 but a different underlying cause. GDR 2000-12-30 Job job000159 is a duplicate of this job. GDR 2000-12-30 See also < http://www.ravenbrook.com/project/p4dt...2001-02-22/version-1.0-support/#job-159>.GDR 2001-07-17: I think the current behaviour is the right thing. It's not a requirement that we prevent fixes. And in any case we want to allow historical fixes. So really the design should state what we expect to happen and we should verify that it does in fact happen. Note that if someone wants to issue a historical fix to a job, then they'll get a warning e-mail from the replicator. Could we support this somehow? How would we identify when this was the right thing to do and when it was a mistake? Or could we write better text in the e-mail? |
| How found | manual_test |
| Evidence | <http://www.ravenbrook.com/project/p4dt...c/2000-12-06/release-0.4.0-test-report/>, item 11. |
| Observed in | 0.4.0 |
| Created by | Gareth Rees |
| Created on | 2000-12-06 15:10:10 |
| Last modified by | Gareth Rees |
| Last modified on | 2001-12-10 19:12:35 |
| History | 2000-12-06 GDR Created. 2000-12-30 GDR Noted relation to job000086 and job000159. |
| Support | Advice for all releases. Symptom. A user fixes a job using Cause. The replicator doesn't revert fixes when it reverts the job. The reason for this is that it can't be sure that the fix caused the change in the job; the fix might have been perfectly legitimate even though the change to the job was wrong. Workaround. If the fix was correct, get someone who has permission to update the job state in Perforce, or transition the corresponding issue in the defect tracker. If the fix was incorrect, delete it from Perforce with |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 22485 | closed | 2001-09-14 13:09:54 | Gareth Rees | Added section explaining how the P4DTI enforces the defect tracker's rules. Explained why fixes aren't deleted even if they cause an illegal change. |