WORKFLOW ENFORCEMENT DESIGN

                        Gareth Rees, 2000-10-27


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 works in the TeamTrack integration:

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:

1. 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).

2. 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

[GDR 2000-10-27] "Re: Paul Goffin: RE: [p4] Bugzilla integration"
(e-mail message); Gareth Rees; Ravenbrook Limited; 2000-10-27.


B. DOCUMENT HISTORY

2000-11-20  RB  Created based on [GDR 2000-10-27]

2001-03-02  RB  Transferred copyright to Perforce under their license.

---

This document is copyright (C) 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.

$Id: //info.ravenbrook.com/project/p4dti/version/1.1/design/workflow-enforcement/index.txt#1 $