head	1.2;
access;
symbols;
locks; strict;
comment	@# @;


1.2
date	2001.08.13.23.37.01;	author kmaples;	state dead;
branches;
next	1.1;

1.1
date	2001.04.30.20.47.10;	author kmaples;	state Exp;
branches;
next	;


desc
@@


1.2
log
@Updated the READMEs
@
text
@Notes on Bugzilla/IssueZilla:

+=======================+
0. CONTENTS:
+=======================+

  1. Original modification notes on the conversion of bugzilla 2.11 to
     IssueZilla by Niels Mayer (npm@@collab.net)

  2. Summary notes and notes on database creation subsequent to modifications
     to support multiple vhosts.

+=======================+
1.  ORIGINAL NOTES:
+=======================+
  
  This is bugzilla straight outta CVS as of 9/27/2000.
  
  Edited by NPM to work w/ tigris, qmail, etc
  
  Further edited by NPM replacing most instances of "bugs"-->"issues"
  "a issue" --> "an issue" etc. 
  
  NPM twiddled with query.cgi to lay things out more reasonably, and
  add space for future enhancements/customizations.
  
  NPM Removed bugs db column 'severity' and replaced it with 'issue-type'.
  Severity seems silly and it's confusing/redundant with priority 'P1'-'P5'.
  Some aspects of 'severity' are handled by 'issue-type', e.g.  you
  distinguish between an enhancement, feature, task, defect, or a patch.
  
  --------------------
  
  To do an upgrade against mozilla.org, move all directories 'CVS' to 'CVS.bak',
  e.g. (in tcsh):
  
  | beral-5-.../sandbox/issuezilla> foreach i (`find . -name CVS`)
  | foreach? mv $i $i.bak
  | foreach? end
  
  Then move all 'CVS.mozilla' to 'CVS':
  
  | beral-6-.../sandbox/issuezilla> foreach i (`find . -name CVS.mozilla`)
  | foreach? mv $i `dirname $i`/CVS
  | foreach? end
  
  
  Then to see what files might have changed, since this version was last
  updated, do:
  
  | beral-7-.../sandbox/issuezilla> cvs -qn update
  
  Then you can either do 'cvs update' and be very careful to watch the output
  of cvs, noting any conflicts between the issuezilla edits and mozilla.org's
  edits... (prior to doing 'cvs update' beware of files marked w/ 'C' when
  you do 'cvs -qn update', as they'll definitely create non-working
  conflict-munged code that needs to be hand edited).
  
  --------------------
  
  Note the following files are to be instantiated by a tigris SANDBOX initialization script
  which someone needs to write...
  
  ./data/params.in             ---> ./data/params
  ./localconfig.in	     ---> ./localconfig
  ./20issue-track.conf.in      ---> ./20issue-track.conf

+=======================+
2.[a]  SUMMARY:
+=======================+
  Support for differentiating issuezilla databases on a per-project has been implemented (this superceedes the previous implementation, which differentiated databases by vhost). The file which controls this behavior is a '.in' file - localconfig.in - which is configured at installation.   At install time, the file defines the following values, usually taken from env.sh:
  
      DATABASE_HOST
      DATABASE_PORT
      DATABASE_USER
      DATABASE_PASSWORD
  
  The file also defines IZ_DATABASE_NAME, which may be expanded to include project id depending on the value of the token IZ_MULTIPLE_PROJECT_DATABASES at installation, and defines SANDBOX, which is used solely by the setup script (checksetup.pl) to orient itself before performing its actions.  The following are the translation rules that can apply:
  
  Assume:
  
      - in env.sh, an environmental IZ_DATABASE_NAME set to 'issues' 
      - a project id X
  
  The flag - '$::use_project_id_database' - will be set (via IZ_MULTIPLE_PROJECT_DATABASES) to produce one of two states:
  
      [false] use database named 'issues'
      
      [true] use database named 'issues_X'
      
  Similarly, localconfig controls the definitions of the two other directories that issuezilla uses to store per-db data on the filesystem - 'shadow' and 'data'.  It sets these as follows, using the same flag as above:
  
      [false] 
          $::data_dir    = "data/";
          $::shadow_dir  = "shadow/";
      [true]
          $::data_dir    = "data/$db_name";
          $::shadow_dir  = "shadow/$db_name";
  
  So that if the flag is set to use anything other than the default database for this installation, it segregates data by host.  
  
  NOTE:  these settings control how a the database name is derived AT RUNTIME.  They have essentially nothing to do with the how a database by the (presumed) matching name is created.  That process is covered below in DATABASE CREATION.

+=======================+
2.[b]  DATABASE CREATION:
+=======================+
  Database creation should now be handled automatically through the web interface (via servlet which calls a series of perl scripts, which in turn call the scripts described below) based on the settings described above; nonetheless, it is possible to perform this manually if necessary.  The script which came with bugzilla has been modified so that it can be used to initialize arbitrary databases; if you set the env variable IZ_DATABASE_NAME to the name of the issuezilla database, you run the setup script as follows:
  
  ./checksetup.pl -d $IZ_DATABASE_NAME -u [db_user] -p [db_password]
  
  Where 'dbuser' and 'dbpassword' are for a user with sufficient mysql priviliges to create databases (usually root).  The script will exit if, at a minimum, 'dbuser' is not supplied.  Note that this does NOT set up the DATABASE_USER permissions for the database - just the database itself.  A separate script with identical arguments has been created to automate the updating of permissions, and is called as follows:
  
  ./checkdbuser.pl -d $IZ_DATABASE_NAME -u [db_user] -p [db_password]
  

NOTE:  here, 'dbuser' and 'dbpassword' MUST be a user with privileges to update the mysql:db database, as well as run a 'mysqladmin reload' - usually root.  In all likelihood, if you created a programmatic user to run the first script (checksetup.pl), it will NOT have sufficient mysql privileges to run the second.



@


1.1
log
@Initial checkin of IssueZilla as a module in advance of removing it from
the sandbox module
@
text
@@

