Workflow enforcement design

1. Introduction

This document describes how the Perforce Defect Tracking Integration enforces the defect tracker's workflow in the Perforce interface.

The readership of this document is anyone developing or maintaining the P4DTI software.

This document is not confidential.

2. Design notes

What we have done for the replication is the reverse of pushing p4's weak security into the defect tracker. We are instead pushing the defect tracker's security into Perforce.

Here's how this worked in the TeamTrack integration. The P4DTI no longer supports integration with TeamTrack, but this description is retained for reference purposes:

When a Perforce user changes a job in Perforce, the replicator tries to find a transition in TeamTrack that corresponds to that change, and attempts to apply that transition on behalf of the user who made the change. TeamTrack applies its rules and may reject the change, or the replicator may fail to find a valid transition and reject the change itself.

What happens when the change is rejected is configurable and depends on an organization's policy, but two options that we expect to be popular are:

• Set the job back to how it was before the illegal change and send e-mail to the user explaining what happened (and enclosing a copy of the offending data so that nothing is lost).

• Stop replicating that job and send e-mail to an administrator explaining what has happened. Wait for the administrator to sort out the problem before starting to replicate again.

This approach should generalize to any defect tracker that enforces rules about who can do what to defect records.

So the integration allows organizations to enforce workflow rules in Perforce. It may look like the workflow rules can be got around in Perforce, but the replicator spots illegal changes to jobs and makes sure that they are dealt with.

One thing the integration isn't able to control is who is able to look at job descriptions. A defect tracker may have rules about who can see which fields or which jobs, but in Perforce if you can see one you can see them all. Is this kind of security important to you as well? This can only really be met by separating out the defects into jobs on different Perforce servers.

A. References

B. Document History

This document is copyright © 2001 Perforce Software, Inc. All rights reserved.

Redistribution and use of this document in any form, with or without modification, is permitted provided that redistributions of this document retain the above copyright notice, this condition and the following disclaimer.

This document is provided by the copyright holders and contributors "as is" and any express or implied warranties, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall the copyright holders and contributors be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this document, even if advised of the possibility of such damage.