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]

---

Copyright 2000 Ravenbrook Limited.  This document is provided "as is",
without any express or implied warranty.  In no event will the authors
be held liable for any damages arising from the use of this document. 
You may make and distribute copies and derivative works of this document
provided that (1) you do not charge a fee for this document or for its
distribution, and (2) you retain as they appear all copyright and
licence notices and document history entries, and (3) you append
descriptions of your modifications to the document history.

$Id$