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


1.1
date	2001.04.11.00.52.37;	author leonardr;	state Exp;
branches;
next	;


desc
@@


1.1
log
@Added document describing how to test the database schema and data changes made by migration scripts.
@
text
@Testing a Helm database migration.

Most typoes of bugs in the migration scripts can be revealed by
running through the test plan. The exceptions are bugs in the role
definitions, since these don't show up for everyone. These bugs can be
caught by using RoleView in a migrated site to check role definitions
in RoleView against the role definitions in
helm/sql/org/tigris/helm/populate_RoleActionResource.sql, for the
branch to which the site was migrated.


SPECIAL CASE: CLASSIC-1.0.0 DESIGN DECISIONS
--------------------------------------------

For the Tigris Classic-1.0.0 migration, we had to make some
assumptions to fill database tables with new fields and to normalize
the permission system.

* All projects start out with the BSD license, and without any short
  or long description.

* Every user except users called "guest" or "root" are assigned to
  domain 2. "root" and "guest" users are assigned to domain 1 (the
  special host domain).

* Users with the "Web Admin" Classic role have the "Host Admin" 1.0.0 role.

* Users with the "Sponsor Admin" Classic role have the "Domain Admin" 
  1.0.0 role.

* Users with config_priv or grant_priv in project_privs for a
  particular project get the "Project Owner" 1.0.0 role in that
  project.

* Users without either of those permissions, but with commit_priv,
  get the "Developer" 1.0.0 role.

* Users without any of those three permissions, but with checkout_priv,
  get the "Observer" 1.0.0 role.

@
