Business Processes

Linas Vepstas linas@linas.org
Mon, 26 Nov 2001 10:19:54 -0600


On Mon, Nov 26, 2001 at 10:18:14AM -0500, Derek Atkins was heard to remark:
> There is one problem with this data-driven model: Many data objects
> contain internal data structures and points to other data objects
> which must be maintained in the data structure but should not or can
> not be displayed/edited to/by the user.
> 
> For example, a Customer has a list of Jobs.  This list is maintained
> in memory similarly to Account maintaining a list of Splits.  The
> Customer GUID is stored in the Job, and the Job 'adds itself' to the
> Customer.  But note that this list of Jobs (or list of Splits) should
> not be stored.
> 
> What I'm reaching here is that we need more information to explain
> what fields in the data structure are ephemeral, as well as which
> should be visible (and when), and which should be editable (and when).

Yes, the conclusion is correct, and we'd need to add such fields.

In WISE, some fields in some objects were visible and/or editable
only by certain users: every field has a ACL on it.

Note also, if we use glade, there's a lot of power there.  Don't want 
the customer address to show?  Don't put it in the glade dialog!
That takes care of that.

The example is a bit off:
I assume that gnucash still has a base object which has a guid in it,
and a pointer to book, and that these are 'hard coded'.  Also,
pointers/references to other objects would not be displayed 'raw',
but would be convertible into links that can be followed.
For example, if you wanted the job gui to display the customer name,
you'd hook a gtk_label to /job/customer/surname.  But if you
wanted the job gui to have a button called 'edit customer', you'd
hook a gtk_button to /job/customer/, the result of that button
would be to pop up a new gui for editing customers.

> It is not, by far, a simple problem.

To give you an idea of the size, WISE implements a full workflow 
system in  10 KLOC (of which 3 KLOC are autogen'd).   By contrast,
gnucash today is over 200 KLOC.  That's right, two-hundred.

I include a sample WISE config below.  I do *NOT* recommend this
syntax, but it gives an idea of what 'the real thing' might look 
like.

--linas

#
# Change this to the address of your WWW server
#
HOST 			your.host.your.domain
#
# Change this to the port of your WWW server (default is 80)
#
PORT			80
#
# Put the name of your organization in between the quotes
#
# ORGANIZATION		"WWW-Integrated Software Environment"
ORGANIZATION		"Widgets and Gadgets, Inc."

#
# A customized image for your WISE pages (ours is default)
# This should be a URL. Below, the leading slash indicates
# that the URL is on the local server.
#
IMAGE			/research.ivv.nasa.gov/images/wisemini.gif
#
# the root directory of the WISE installation
#
ROOT			/usr/local/wise-1.0
#
# The page background.  A URL, in general.
#
BACKGROUND		/research.ivv.nasa.gov/images/chalk.jpg

###################################################################
# Below follows a definition of a "typical" software bug 
# tracking environment.  See the  README.WPL file for information 
# about the WISE Programming Language (WPL) used to create this 
# environment.  We begin with some general notes.
#
# Linux Notes:
# PORT: This is the mSQL port number.  It is usually either 1112 (when
#       mSQL v1.0.x is installed as root) or 4333 (when mSQL v1.0.x is
#       installed and run under a user id.) For mSQL v2.0 running as
#       root, this is 1114, although this number is configurable 
#       in the Hughes/msql.conf file.
#
# HOST: This should always be "localhost" and not "some.where.some.domain"
#       This restriction is made for security reasons. See README.linux 
#       for details.
#
# Project names (the token that immediately follows the keyword "PROJECT")
#       are limited to 8 characters. I tried to fix this, but couldn't. 
#       Sorry.  The project description (the part in quotation marks)
#       does not have this limit.
#
# DATABASE: It appears that DATABASE must have the same name as the project
#
# Syntax errors and misconfiguration in this file will usually manifest
#       as compile time bugs.  If you have a mystery bug, check your work!
#
###################################################################
#
# Typical Software Bug Tracking Environment
# ------------------------------------i----
# The structures below mock up a simple, prototypical software
# bug tracking environment.  They define roles for developers, a builder, 
# a test and a team-lead/project-manager.  These roles are constrained
# to perform certain actions: developers can modify the abstract,
# the synopsis, and put the defect into working state. They cannot
# put the defect into "built" or "testing" state. Note that this
# is a quick hack, and hasn't yet withstood the test of time.
# Some common features, such as those found in CMVC, are missing.
#
# This PROJECT does NOT provide the sort of fields and functions
# needed for new software architecture or module design. It is 
# strictly formulated for bug tracking.  I may get around to doing 
# a wpl for s/w development in the near future.
#
# Yes, this particular wpl file should be more carefully documented.
# I do make all sorts of assumptions about work flow and process
# here that may not be obvious if you've never done it this way before.
#
# Linas Vepstas December 1996, January 1997

# abstract -- a one-line summary
# synopsis -- a paragraph or two describing the problem
# log -- a log of additional comments too long to fit in the synopsis.
# originator -- who reported the problem
# owner -- person responsible for making fix.
# state -- open (new), working (being fixed) fixed (fix has been
#          dropped into source control system, but not yet built.)
#          testing (its getting soaked in the bucket), verify (passed
#          testing, originator should verify), closed (originator agrees
#          with final outcome), returned (rejected by development team 
#          and/or a duplicate report already exists).
# category -- accepted by developer, error acknowledged, or unreproducible
#             or duplicate.
# component -- server, client, etc (you should change this to suit
#              your shop.)
# duedate -- the expected date that this will be fixed.
# duplicate -- number of a duplicate issue.
#
# severity -- showstopper (cannot work around the problem) 
#             mustfix (workaround possible, but ugly)
#             annoyance (workaround possible and reasonable)
#             suggestion (a better way of doing things)
# priority -- immediately (fix in 24 hours), soon (2 week turnaround)
#             eventually (fix in next release), memo (gee whiz...)
# target -- name of a release or build in which the fix will be published.

PROJECT bugtrack "Defect Management" {
	DATABASE	bugtrack
	HOST		localhost
#	PORT		1112
	PORT		1114
	IMAGE		/research.ivv.nasa.gov/images/wisemini.gif

	abstract		TEXT		60
	synopsis		TEXTAREA	900
	log			LOG		
	originator 		TEXT		30
	owner	 		TEXT		30
	submitted		DATE
	duedate			DATE
	target			TEXT		20
	severity 		RADIO
	priority 		RADIO
	state			SELECT
	component		SELECT
	category		SELECT
	duplicate		INT
}

TDL bugtrack {
	abstract	60
#	submitted	11
	severity	11
	priority	11
#	duedate		11
	target		11
	state		11
#	category	11
	component	11
}


# There are multiple roles:
# viewers, who can view a limited amount of information
# developers, who write and drop code
# builders, who maintain releases
# testers, who test releases
# project managers who have broad powers.

ROLE anonymous ISA viewer ON PROJECT bugtrack;
ROLE john ISA viewer ON PROJECT bugtrack;
ROLE becky ISA viewer ON PROJECT bugtrack;
# ROLE linas ISA viewer ON PROJECT bugtrack;

# ROLE linas ISA developer ON PROJECT bugtrack;
ROLE bvarov ISA developer ON PROJECT bugtrack;
ROLE nikolay ISA developer ON PROJECT bugtrack;
ROLE anton ISA developer ON PROJECT bugtrack;

ROLE jackie ISA builder ON PROJECT bugtrack;
# ROLE linas ISA builder ON PROJECT bugtrack;

ROLE jackie ISA tester ON PROJECT bugtrack;
# ROLE linas ISA tester ON PROJECT bugtrack;

ROLE linas ISA teamlead ON PROJECT bugtrack;

# anonymous viewers can see the to-do list
TDLVIEW viewer SEES
	WHEN project <> BLANK
	ON PROJECT bugtrack;

TDLVIEW developer SEES
	WHEN project <> BLANK
	ON PROJECT bugtrack;

TDLVIEW builder SEES
	WHEN project <> BLANK
	ON PROJECT bugtrack;

TDLVIEW tester SEES
	WHEN project <> BLANK
	ON PROJECT bugtrack;

TDLVIEW teamlead SEES
	WHEN project <> BLANK 
	ON PROJECT bugtrack;

# =======================================================
# anyone can create a new problem report.
NEWACCESS ALL
	HAVE READWRITE ACCESS
	ON FIELD abstract
	ON PROJECT bugtrack;

# anyone can append to the log
NEWACCESS ALL
	HAVE READWRITE ACCESS
	ON FIELD log
	ON PROJECT bugtrack;

#can't pretend to be someone else
NEWACCESS ALL
	HAVE READONLY ACCESS
	ON FIELD originator
	ON PROJECT bugtrack = $USER$;

#anyone can try to assign the owner.
NEWACCESS ALL
	HAVE READWRITE ACCESS
	ON FIELD owner
	ON PROJECT bugtrack = $USER$;

#can't fiddle with the origination date
NEWACCESS ALL
	HAVE READONLY ACCESS
	ON FIELD submitted
	ON PROJECT bugtrack = $TODAY$;

# can set severity level
NEWACCESS ALL
	HAVE READWRITE ACCESS
	ON FIELD severity
	ON PROJECT bugtrack = 0-no rating,1-showstopper,2-serious,3-annoyance,4-suggestion;

NEWACCESS ALL
	HAVE READWRITE ACCESS
	ON FIELD priority
	ON PROJECT bugtrack = 0-no rating,1-immediately,2-soon,3-eventually,4-memo;

# new problems can only be created in the "open" state.
NEWACCESS ALL
	HAVE READONLY ACCESS
	ON FIELD state
	ON PROJECT bugtrack = open;

# can try to guess the subcomponent
NEWACCESS ALL
	HAVE READWRITE ACCESS
	ON FIELD component
	ON PROJECT bugtrack = unknown,server,client,database,sysadmin,documentation;


#don't show duedate, etc.
NEWACCESS FIELD duedate
	IS HIDDEN TO ALL
	ON PROJECT bugtrack;

NEWACCESS FIELD target
	IS HIDDEN TO ALL
	ON PROJECT bugtrack;

NEWACCESS FIELD category
	IS HIDDEN TO ALL
	ON PROJECT bugtrack;

NEWACCESS FIELD duplicate
	IS HIDDEN TO ALL
	ON PROJECT bugtrack;

NEWACCESS FIELD synopsis
	IS HIDDEN TO ALL
	ON PROJECT bugtrack;

# Note that "duedate" and "synopsis" are not even mentioned
# in the NEWACCESS area ... this means that we don't want these
# field to show up in the new form.

# =======================================================
# some fields are denied to viewers
#
# VIEWACCESS FIELD submitted
# 	IS HIDDEN TO viewer
# 	ON PROJECT bugtrack;
# VIEWACCESS FIELD component
# 	IS HIDDEN TO viewer
# 	ON PROJECT bugtrack;

# developer can add to the log
VIEWACCESS viewer
	HAS READWRITE ACCESS
	ON FIELD log
	ON PROJECT bugtrack;

# originator of problem can change the severity level
# N.B. this is currently broken in wise. I'll get around to it ...
VIEWACCESS viewer
	HAS READWRITE ACCESS
	ON FIELD severity
	WHEN originator = $USER$ AND state <> closed AND state <> verify
	ON PROJECT bugtrack = 0-no rating,1-showstopper,2-serious,3-annoyance,4-suggestion;

VIEWACCESS viewer
	HAS READWRITE ACCESS
	ON FIELD priority
	WHEN originator = $USER$ AND state <> closed AND state <> verify
	ON PROJECT bugtrack = 0-no rating,1-immediately,2-soon,3-eventually,4-memo;

# originator can reopen a returned defect, or can close it.
# However, they can only close defects that are in rejected state,
# or in verify state.
VIEWACCESS viewer
	HAS READWRITE ACCESS
	ON FIELD state
	WHEN originator = $USER$ AND state = verify
	ON PROJECT bugtrack = open,closed;

VIEWACCESS viewer
	HAS READWRITE ACCESS
	ON FIELD state
	WHEN originator = $USER$ AND state = returned
	ON PROJECT bugtrack = open,closed;

VIEWACCESS viewer
	HAS READWRITE ACCESS
	ON FIELD state
	WHEN originator = $USER$ AND state = duplicate
	ON PROJECT bugtrack = open,closed;

# Originator can assign the owner
VIEWACCESS viewer
	HAS READWRITE ACCESS
	ON FIELD owner
	WHEN originator = $USER$ AND state <> closed AND state <> verify
	ON PROJECT bugtrack;

# =======================================================

# developers can change the abstract
VIEWACCESS developer
	HAS READWRITE ACCESS
	ON FIELD abstract
        WHEN state = open OR state = working OR state = fixed OR state = returned OR state = duplicate
	ON PROJECT bugtrack;

# developer can modify the synopsis
VIEWACCESS developer
	HAS READWRITE ACCESS
	ON FIELD synopsis
        WHEN state = open OR state = working OR state = fixed OR state = returned OR state = duplicate
	ON PROJECT bugtrack;

# developer can add to the log
VIEWACCESS developer
	HAS READWRITE ACCESS
	ON FIELD log
	ON PROJECT bugtrack;

# can't change the originator
VIEWACCESS developer
	HAS READONLY ACCESS
	ON FIELD originator
	ON PROJECT bugtrack = $USER$;

# developer can reassign owner
VIEWACCESS developer
	HAS READWRITE ACCESS
	ON FIELD owner
        WHEN state = open OR state = working OR state = fixed OR state = returned OR state = duplicate
	ON PROJECT bugtrack;

# can't fiddle with the origination date
VIEWACCESS developer
	HAS READONLY ACCESS
	ON FIELD submitted
	ON PROJECT bugtrack;

# developer can modify severity level
VIEWACCESS developer
	HAS READWRITE ACCESS
	ON FIELD severity
        WHEN state = open OR state = working OR state = fixed OR state = returned OR state = duplicate
	ON PROJECT bugtrack = 0-no rating,1-showstopper,2-serious,3-annoyance,4-suggestion;

VIEWACCESS developer
	HAS READWRITE ACCESS
	ON FIELD priority
        WHEN state = open OR state = working OR state = fixed OR state = returned OR state = duplicate
	ON PROJECT bugtrack = 0-no rating,1-immediately,2-soon,3-eventually,4-memo;

# developer can put defect into working state (they're are
# working on it,)  or fixed state (they dropped code into repository).
# they can't claim its been built, tested or closed.
VIEWACCESS developer
	HAS READWRITE ACCESS
	ON FIELD state
        WHEN state = open OR state = working OR state = fixed OR state = returned OR state = duplicate
	ON PROJECT bugtrack = open,working,fixed,returned,duplicate;

# developer can reassign component
VIEWACCESS developer
	HAS READWRITE ACCESS
	ON FIELD component
        WHEN state = open OR state = working OR state = fixed OR state = returned OR state = duplicate
	ON PROJECT bugtrack = unknown,server,client,database,sysadmin,documentation;

# developer can accept or reject
VIEWACCESS developer
	HAS READWRITE ACCESS
	ON FIELD category
        WHEN state = open OR state = working OR state = fixed OR state = returned OR state = duplicate
	ON PROJECT bugtrack = accept,error,unreproducible,enhancement,duplicate;

# developer can change due date
VIEWACCESS developer
	HAS READWRITE ACCESS
	ON FIELD duedate
        WHEN state = open OR state = working OR state = fixed OR state = returned OR state = duplicate
	ON PROJECT bugtrack;

VIEWACCESS developer
	HAS READWRITE ACCESS
	ON FIELD target
        WHEN state = open OR state = working OR state = fixed OR state = returned OR state = duplicate
	ON PROJECT bugtrack;

VIEWACCESS developer
	HAS READWRITE ACCESS
	ON FIELD duplicate
        WHEN state = open OR state = working OR state = fixed OR state = returned OR state = duplicate
	ON PROJECT bugtrack;

# =======================================================

# builder can only view the abstract
VIEWACCESS builder
	HAS READONLY ACCESS
	ON FIELD abstract
	ON PROJECT bugtrack;

# builder can only read the synopsis
VIEWACCESS builder
	HAS READONLY ACCESS
	ON FIELD synopsis
	ON PROJECT bugtrack;

# builder can add to the log
VIEWACCESS builder
	HAS READWRITE ACCESS
	ON FIELD log
	ON PROJECT bugtrack;

# builder can reassign owner
VIEWACCESS builder
	HAS READWRITE ACCESS
	ON FIELD owner
        WHEN state = fixed OR state = built
	ON PROJECT bugtrack = $USER$;

# builder can put defect into built state (they've compiled
# and built it) or working state (they've rejected the code).
# they can't claim its being tested or closed.
VIEWACCESS builder
	HAS READWRITE ACCESS
	ON FIELD state
        WHEN state = fixed OR state = built
	ON PROJECT bugtrack = working,built;

# builder can change due date
VIEWACCESS builder
	HAS READWRITE ACCESS
	ON FIELD duedate
        WHEN state = fixed OR state = built
	ON PROJECT bugtrack;

VIEWACCESS builder
	HAS READWRITE ACCESS
	ON FIELD target
        WHEN state = fixed OR state = built
	ON PROJECT bugtrack;


# =======================================================

# builder can only view the abstract
VIEWACCESS tester
	HAS READONLY ACCESS
	ON FIELD abstract
	ON PROJECT bugtrack;

# tester can only read the synopsis
VIEWACCESS tester
	HAS READONLY ACCESS
	ON FIELD synopsis
	ON PROJECT bugtrack;

# tester can add to the log
VIEWACCESS tester
	HAS READWRITE ACCESS
	ON FIELD log
	ON PROJECT bugtrack;

# tester can reassign owner
VIEWACCESS tester
	HAS READWRITE ACCESS
	ON FIELD owner
        WHEN state = built OR state = testing OR state = verify
	ON PROJECT bugtrack = $USER$;

# tester can put defect into testing state (they're running
# the test cycle, but that may take a week.) or working state 
# (they've rejected the code as bad) or verify (it tested out OK,
# and now its up to originator to agree that they are happy).
VIEWACCESS tester
	HAS READWRITE ACCESS
	ON FIELD state
        WHEN state = built OR state = testing OR state = verify
	ON PROJECT bugtrack = working,testing,verify;

# tester can change due date
VIEWACCESS tester
	HAS READWRITE ACCESS
	ON FIELD duedate
        WHEN state = built OR state = testing OR state = verify
	ON PROJECT bugtrack;


# =======================================================
#teamleads are all-powerful, and can pretty much do anything.

# teamleads can change the abstract
VIEWACCESS teamlead
	HAS READWRITE ACCESS
	ON FIELD abstract
	ON PROJECT bugtrack;

# teamlead can modify the synopsis
VIEWACCESS teamlead
	HAS READWRITE ACCESS
	ON FIELD synopsis
	ON PROJECT bugtrack;

# teamlead can add to the log
VIEWACCESS teamlead
	HAS READWRITE ACCESS
	ON FIELD log
	ON PROJECT bugtrack;

# teamlead can change the originator
VIEWACCESS teamlead
	HAS READWRITE ACCESS
	ON FIELD originator
	ON PROJECT bugtrack;

# teamlead can reassign owner
VIEWACCESS teamlead
	HAS READWRITE ACCESS
	ON FIELD owner
	ON PROJECT bugtrack;

# teamlead can change origination date
VIEWACCESS teamlead
	HAS READWRITE ACCESS
	ON FIELD submitted
	ON PROJECT bugtrack;

# teamlead can modify severity level
VIEWACCESS teamlead
	HAS READWRITE ACCESS
	ON FIELD severity
	ON PROJECT bugtrack = 0-no rating,1-showstopper,2-serious,3-annoyance,4-suggestion;

VIEWACCESS teamlead
	HAS READWRITE ACCESS
	ON FIELD priority
	ON PROJECT bugtrack = 0-no rating,1-immediately,2-soon,3-eventually,4-memo;
# teamlead can put defect into any state
VIEWACCESS teamlead
	HAS READWRITE ACCESS
	ON FIELD state
	ON PROJECT bugtrack = open,working,fixed,built,testing,returned,duplicate,verify,closed;

# teamlead can reassign component
VIEWACCESS teamlead
	HAS READWRITE ACCESS
	ON FIELD component
	ON PROJECT bugtrack = unknown,server,client,database,sysadmin,documentation;

# teamlead can accept or reject
VIEWACCESS teamlead
	HAS READWRITE ACCESS
	ON FIELD category
	ON PROJECT bugtrack = accept,error,unreproducible,enhancement,duplicate;

# teamlead can change due date
VIEWACCESS teamlead
	HAS READWRITE ACCESS
	ON FIELD duedate
	ON PROJECT bugtrack;

VIEWACCESS teamlead
	HAS READWRITE ACCESS
	ON FIELD target
	ON PROJECT bugtrack;

VIEWACCESS teamlead
	HAS READWRITE ACCESS
	ON FIELD duplicate
	ON PROJECT bugtrack;

# =======================================================

TDLACTION ALL
	CAN CALL NEWISSUE
	LABEL "Open New Issue"
	ON PROJECT bugtrack;

VIEWACTION viewer
	CAN CALL SUBMITISSUE
	LABEL "Modify Issue"
	ON PROJECT bugtrack;

VIEWACTION developer
	CAN CALL SUBMITISSUE
	LABEL "Modify Issue"
	ON PROJECT bugtrack;

VIEWACTION builder
	CAN CALL SUBMITISSUE
	LABEL "Modify Issue"
	ON PROJECT bugtrack;

VIEWACTION tester
	CAN CALL SUBMITISSUE
	LABEL "Modify Issue"
	ON PROJECT bugtrack;

VIEWACTION teamlead
	CAN CALL SUBMITISSUE
	LABEL "Modify Issue"
	ON PROJECT bugtrack;

###################################################################
# ================ Thats all folks ! =======================
-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933