head	1.5;
access;
symbols
	TIGRIS_1_1_0RC2:1.4
	TIGRIS_1_1_0RC1:1.4
	TIGRIS_1_1:1.4.0.8
	TIGRIS_1_0_8:1.4
	TIGRIS_1_0_8RC3:1.4
	TIGRIS_1_0_8RC2:1.4
	TIGRIS_1_0_8RC1:1.4
	TIGRIS_1_0_7:1.4
	TIGRIS_1_0_7RC3:1.4
	TIGRIS_1_0_7RC2:1.4
	TIGRIS_1_0_7RC1:1.4
	TIGRIS_1_0_6:1.4
	TIGRIS_1_0_6RC5:1.4
	TIGRIS_1_0_6RC4:1.4
	TIGRIS_1_0_6RC3:1.4
	TIGRIS_1_0_6RC2:1.4
	TIGRIS_1_0_6RC1:1.4
	TIGRIS_1_0_5:1.4
	TIGRIS_1_0_5RC6:1.4
	TIGRIS_1_0_5RC5:1.4
	TIGRIS_1_0_5RC4:1.4
	TIGRIS_1_0_5RC3:1.4
	TIGRIS_1_0_5RC2:1.4
	TIGRIS_1_0_5RC1:1.4
	TIGRIS_1_0_4:1.4
	TIGRIS_1_0_3:1.4
	TIGRIS_1_0_2:1.4
	TIGRIS_1_0_1:1.4
	TIGRIS_1_0:1.4.0.10
	TIGRIS_1_0_0:1.4
	TIGRIS_1_0_0_RC1:1.4.0.6
	dlr:1.1.1
	TIGRIS_0_9_2_4:1.4
	TIGRIS_0_9_2_3:1.4
	HELM_PEER_PORT_BRANCH:1.1.1.2
	TURBINE_PEER:1.4
	TIGRIS_0_9_2_1:1.4
	TIGRIS_0_9_2:1.4.0.4
	TIGRIS_0_9_0:1.4.0.2
	TIGRIS_0_8_4:1.3.0.2
	NEWHELM:1.1.1.1
	TIGRIS_NOV_12_2000:1.1.1
	OLDHELM:1.1.0.4
	TIGRIS_NOV_11_2000:1.1
	TIGRIS_SEP_13_2000:1.1.0.2;
locks; strict;
comment	@# @;


1.5
date	2001.08.14.00.38.21;	author kmaples;	state Exp;
branches;
next	1.4;

1.4
date	2000.12.20.20.43.56;	author kmaples;	state Exp;
branches;
next	1.3;

1.3
date	2000.11.18.01.58.16;	author kmaples;	state Exp;
branches;
next	1.2;

1.2
date	2000.11.12.22.57.33;	author dlr;	state Exp;
branches;
next	1.1;

1.1
date	2000.09.28.18.14.13;	author kmaples;	state Exp;
branches
	1.1.1.1;
next	;

1.1.1.1
date	2000.11.12.21.17.26;	author dlr;	state Exp;
branches;
next	1.1.1.2;

1.1.1.2
date	2001.02.21.00.35.52;	author dlr;	state Exp;
branches;
next	;


desc
@@


1.5
log
@Rough updating of README
@
text
@Project Creation Scripts:

$Id: README.txt,v 1.4 2000/12/20 20:43:56 kmaples Exp $

OVERVIEW:
=========================
The perl side of project creation consists of two sets of scripts: 'parent' scripts (scripts named in the fashion 'ScriptName', or more accurately 'ComponentAction'), and 'child' scripts (scripts named in fashion 'application-component-action').  Some examples are:

 PARENTS:            CHILDREN:
-----------------------------------------------------------------------
 ModuleAdd           apache-project-add
 ModuleDelete        apache-project-delete
 ModuleEdit          apache-project-edit
 ProjectAdd          issuezilla-module-add
 ProjectDelete       issuezilla-module-delete
 ProjectEdit         issuezilla-project-add
 					 issuezilla-project-delete
                     cvs-module-add
                     cvs-module-delete
                     cvs-module-edit
                     cvs-project-add
                     cvs-project-delete
                     cvs-project-edit

Parent scripts primarily serve two functions - a consistent wrapper for the execution of the child scripts, and a unified logging framework for each parent [see LOGGING below].  The relationship between parent scripts and child scripts is controlled and defined by appropriately named "ParentChildArgumentBridge.pl", which maps the arguments of the parent to the arguments each child requires.  The parent scripts should be called with the following nine arguments (in the posix '--argument=value' or '--argument value' form):

 ARG:                TYPE:      EXAMPLE:                  MAPS TO:
-----------------------------------------------------------------------
 domain_name         string     foo.collab.net            HELM_DOMAIN.NAME
 project_name        string     project                   HELM_PROJECT.NAME 
 project_id          int        15                        HELM_PROJECT.PROJECT_ID
 brand_name          string     tigris                    ?
 description         string     'a really great project'  HELM_PROJECT.SHORT_DESCRIPTION
 module_name         string     www                       HELM_MODULE.NAME
 module_description  string     'a fabulous module'       HELM_MODULE.DESCRIPTION
 is_web              boolean    1 or 0                    HELM_MODULE.IS_WEB
 is_public	         boolean    1 or 0                    HELM_PROJECT.IS_PRIVATE 	

Arguments for which the calling context has no meaning or use may be omitted.  Parents, in turn, are responsible for calling all of the 'child' scripts needed to fulfill their namesake (e.g., "ProjectAdd" is responsible for calling all of the child scripts needed to complete the addition of a project).

Note that because the presumption is that parent scripts are actually being invoked by a java servlet (responsible for doing the database work, mail-related work, etc.), the list of actions that a parent performs is NOT comprehensive.

IMPLEMENTED:
=========================
The following parent scripts, and the listed child scripts that they call, are considered fully implemented:

ProjectAdd:
	cvs-project-add
	apache-project-add
	issuezilla-project-add
ModuleAdd:
	cvs-module-add
	issuezilla-module-add
ProjectDelete:
	cvs-project-delete
	apache-project-delete
	issuezilla-project-delete
ModuleDelete:
	cvs-module-delete
	issuezilla-module-delete

The following are partially implemented:
    
ProjectEdit:
        [no op]
ModuleEdit:
        cvs-module-edit

LOGGING:
=========================
Script output from the parent scripts and subsequently called scripts are sent to the following logfile:

	$SANDBOX/log/debug/HelmPerlScripts.log

stdout is sent to the filter LogFilter, a perl script which determines the level of verbosity to send to the file.

DEPENDENCIES IN ENV:
=========================
The scripts assumes that the following are set in the environment of the user or process calling the scripts:

	$SANDBOX
	$HTDOC_ROOT
	$DATABASE_USER
	$DATABASE_PASSWORD

STATIC PATH FRAGMENTS:
=========================
The following static path fragments are defined in the scripts, and therefore introduce architectural dependencies:

	From $SANDBOX:
		helm/perl/scripts/        - where the scripts themselves are found.
		debug/log/                - where logfiles are deposited.
		data/helm/cvs/repository/ - root of local cvs repository
		data/helm/cvs/            - root of local cvs installation.
	From $HTDOC_ROOT:
		look/www/templates/       - location of default content for
		                            web-related modules.
		
KNOWN ISSUES:
=========================
- no rules for checking @@ARGV
- non-portable calls to mysql
- the issuezilla-*-delete scripts are straight system calls, whereas the 
  issuezilla-*-add scripts have been rewritten to use DBI
- field names are hard-coded in sql statements
- no 'real' detainting for setuid scripts

@


1.4
log
@I told edk I would, and so I did; the perl project creation scripts now use
posix-style named args.
@
text
@d3 1
a3 1
$Id: README.txt,v 1.3 2000/11/18 01:58:16 kmaples Exp $
d17 3
a19 3
 MemberAdd           issuezilla-project-delete
 MemberDelete        cvs-module-add
 MemberEdit          cvs-module-delete
d37 1
a37 5
*issues_realname     string     'Kevin Maples'            User.name     
*issues_username     string     kmaples                   User.loginID
 issues_role         string     'admin' or 'user'         

(NOTE: issues_realname and issues_username can be a colon-separated list of values - this is used to optimize the setting of a large number of users in the same project the same role.  The number of elements in these lists need to match.)
a60 4
MemberAdd:
        issuezilla-user-add
MemberDelete:
        issuezilla-user-delete
a67 4
MemberEdit:
	issuezilla-user-edit


d71 3
a73 1
If a parent script is called from an interactive shell, log output is sent to stdout.  Otherwise, it is sent to the following logfile:
d75 1
a75 1
	$SANDBOX/log/HelmPerlScripts.log
d79 1
a79 1
The scripts assume that the following are set in the environment:
a82 1
	$IZ_DATABASE_NAME
d92 1
a92 1
		log/                      - where logfiles are deposited.
@


1.3
log
@Makeing the readme more like reality (maping args to HELM tables).
@
text
@d3 1
a3 1
$Id: README.txt,v 1.2 2000/11/12 22:57:33 dlr Exp $
d25 1
a25 1
Parent scripts primarily serve two functions - a consistent wrapper for the execution of the child scripts, and a unified logging framework for each parent [see LOGGING below].  The relationship between parent scripts and child scripts is controlled and defined by appropriately named "ParentChildArgumentBridge.pl", which maps the arguments of the parent to the arguments each child requires.  The parent scripts should be called with the following nine arguments (in the following order):
d43 1
a43 1
Arguments for which the calling context has no meaning or use need to be 'padded' with a string (we recommend the string 'null').  Parents, in turn, are responsible for calling all of the 'child' scripts needed to fulfill their namesake (e.g., "ProjectAdd" is responsible for calling all of the child scripts needed to complete the addition of a project).
@


1.2
log
@Resolved merge conflicts.
@
text
@d3 1
a3 1
$Id: README.txt,v 1.1.1.1 2000/11/12 21:17:26 dlr Exp $
d34 3
a36 3
 module_name         string     www
 module_description  string     'a fabulous module'
 is_web              boolean    1 or 0
d39 1
a39 1
 issues_role         string     'admin' or 'user'     
@


1.1
log
@Initial checkin of README for the project creation scripts.
@
text
@d3 2
d14 6
a19 6
 ProjectAdd          bugzilla-module-add
 ProjectDelete       bugzilla-module-delete
 ProjectEdit         bugzilla-project-add
                     bugzilla-project-delete
                     cvs-module-add
                     cvs-module-delete
d27 1
a27 1
 ARG:                TYPE:      EXAMPLE:
d29 5
a33 4
 domain_name         string     foo.collab.net
 project_name        string     project   
 brand_name          string     tigris
 description         string     'a really great project'
d37 5
a41 3
 was_web             boolean    1 or 0
 is_private          boolean    1 or 0
 bugs_password       string     password (this is clear text!)
d54 1
a54 1
	bugzilla-project-add
d57 1
a57 1
	bugzilla-module-add
d61 1
a61 1
	bugzilla-project-delete
d64 5
a68 5
	bugzilla-module-delete
ProjectEdit:
	[no op]
ModuleEdit:
    cvs-module-edit
d72 6
a77 6
UserAdd:
	bugzilla-user-add
UserEdit:
	bugzilla-user-edit
UserDelete:
	bugzilla-user-delete
d93 1
a93 1
	$DATABASE_NAME
d114 2
a115 2
- the bugzilla-*-delete scripts are straight system calls, whereas the 
  bugzilla-*-add scripts have been rewritten to use DBI
@


1.1.1.1
log
@Merging newhelm tree into helm, as per IZ issue #557.  Previous major version of helm is tagged TIGRIS_NOV_11_2000.
@
text
@a2 2
$Id: README.txt,v 1.5 2000/11/07 03:02:07 kmaples Exp $

d12 6
a17 6
 ProjectAdd          issuezilla-module-add
 ProjectDelete       issuezilla-module-delete
 ProjectEdit         issuezilla-project-add
 MemberAdd           issuezilla-project-delete
 MemberDelete        cvs-module-add
 MemberEdit          cvs-module-delete
d25 1
a25 1
 ARG:                TYPE:      EXAMPLE:                  MAPS TO:
d27 4
a30 5
 domain_name         string     foo.collab.net            HELM_DOMAIN.NAME
 project_name        string     project                   HELM_PROJECT.NAME 
 project_id          int        15                        HELM_PROJECT.PROJECT_ID
 brand_name          string     tigris                    ?
 description         string     'a really great project'  HELM_PROJECT.SHORT_DESCRIPTION
d34 3
a36 5
*issues_realname     string     'Kevin Maples'            User.name     
*issues_username     string     kmaples                   User.loginID
 issues_role         string     'admin' or 'user'     

(NOTE: issues_realname and issues_username can be a colon-separated list of values - this is used to optimize the setting of a large number of users in the same project the same role.  The number of elements in these lists need to match.)
d49 1
a49 1
	issuezilla-project-add
d52 1
a52 1
	issuezilla-module-add
d56 1
a56 1
	issuezilla-project-delete
d59 5
a63 5
	issuezilla-module-delete
MemberAdd:
        issuezilla-user-add
MemberDelete:
        issuezilla-user-delete
d67 6
a72 6
ProjectEdit:
        [no op]
ModuleEdit:
        cvs-module-edit
MemberEdit:
	issuezilla-user-edit
d88 1
a88 1
	$IZ_DATABASE_NAME
d109 2
a110 2
- the issuezilla-*-delete scripts are straight system calls, whereas the 
  issuezilla-*-add scripts have been rewritten to use DBI
@


1.1.1.2
log
@Replacing the HEAD with the HELM_PEER_PORT_BRANCH.
@
text
@d3 1
a3 1
$Id: README.txt,v 1.4 2000/12/20 20:43:56 kmaples Exp $
d25 1
a25 1
Parent scripts primarily serve two functions - a consistent wrapper for the execution of the child scripts, and a unified logging framework for each parent [see LOGGING below].  The relationship between parent scripts and child scripts is controlled and defined by appropriately named "ParentChildArgumentBridge.pl", which maps the arguments of the parent to the arguments each child requires.  The parent scripts should be called with the following nine arguments (in the posix '--argument=value' or '--argument value' form):
d34 3
a36 3
 module_name         string     www                       HELM_MODULE.NAME
 module_description  string     'a fabulous module'       HELM_MODULE.DESCRIPTION
 is_web              boolean    1 or 0                    HELM_MODULE.IS_WEB
d39 1
a39 1
 issues_role         string     'admin' or 'user'         
d43 1
a43 1
Arguments for which the calling context has no meaning or use may be omitted.  Parents, in turn, are responsible for calling all of the 'child' scripts needed to fulfill their namesake (e.g., "ProjectAdd" is responsible for calling all of the child scripts needed to complete the addition of a project).
@


