Observations

Both CEE/collabnet and kenai have roles assigned to users and permissions assigned to roles. CEE in addition has groups where users can be assigned to multiple groups and groups can have multiple users. On CEE roles can also be assigned to groups and thus users have their own roles and in addition derived roles assigned by group membership. On CEE there are project roles and domain roles while on kenai there are basically only project roles.

The permission systems of CEE´s issuezilla is integrated with the main permission system. The bugzilla permission system is coupled with Kenai's permission system, as described here: http://kenai.com/projects/ooo-migration/lists/discuss/archive/2010-02/message/5. The bugzilla permission system also has groups.

On CEE permissions for roles are defined by allowing or disallowing a fixed set of Actions on Resource Groups which are defined by regular expressions that are matched against paths of the resources. Kenai has a fixed set of Permissions for some Features which can be enabled or disabled for a role in a project. Kenai has a fixed set of roles while on CEE has some fixed roles and a domain-administrator can also define new roles and assign permission for actions on resource groups to them.

On Kenai usernames must have at least 3 characters while on CEE also shorter usernames with just one or two characters are allowed. We currently have 692 users which have just a 2 character username and there also exists 33 users with just one character as username among which also just a single digit has been used. Additionally usernames starting with a digit a problematic on kenai.

On CEE only some kind of hash value or encrypted value for the password is stored in the database.

CEE has a Domain Administrator group. On kenai a domain admin privilege is defined by having the admin role in the global project, which is a kenai internal project.

Kenai has the concept of inactive users. Those are not listed in the people list and mail forwarding to user@domain is disabled for those. We should consider users who did not log in for more than 18 month as inactive.

Migration

For usernames there is an open kenai issue to allow also two character usernames. If this issue will not be fixed those short usernames must be migrated by prefixing the username with ooo- or similar. Additionally there is the problem the kenai would not handle usernames which start with a digit, those must be renamed as well. The strategy we follow will be based on the number of active users that have such accounts (see issue OOO_MIGRATION-1). Additionally the constraint that there can be only 1 account with a given email address has to be handled (see OOO_MIGRATION-2). Some statistics will help to find to best migration strategy.

For Roles a mapping between currently used roles and new roles must be created. Because the permission system on CEE is more complex after migration some users might have to get more rights on the site than they previously had. But that is probably OK because roles with such fine grained permissions like they are currently used on the CEE/collabnet OpenOffice.org website are not really needed.

Resource Groups can not be migrated because that concept does not exist on kenai.

If kenai can not get a new feature of domain wide roles those must be matched to project roles and users will have to get the corresponding project role in all existing projects.

Groups generally can not be migrated. There is one important exception though: Much of the current workflow on OpenOffice.org´s issuetracker depends on membership in a "canconfirm" group this will have to be migrated to the corresponding "canconfirm" group in bugzillas permission system which is separate from the main kenai permission system.

For derived roles will also have to be mapped to user specific roles.

Passwords can not be migrated, during migration new random passwords will be generated for the users and an email with their username and password will be send to them. Note: I'd appreciate it if we would not send those two together in one email, as it happened after the NetBeans migration, since I would consider this a security issue. ("I" here means: FS)

Domain Admin privileges are not migrated by the netadmin migration tools.

Migration Details

The data dump we will get from collabnet will contain a dump of the mysql tigris database which contains the tables which define users, roles and mailinglists.

We can leverage much of the migration script work the netbeans team has done during their migration, but some OOo specific changes will be required and some additional things will be needed. Some of the OOo tigris tables do contain additional columns compared to what is being used in the netbeans migration scripts. This is one area where adoption is needed. Also netbeans had different previous roles and the mapping of old to new roles is hardcoded in the migration scripts and must be changed to OOo needs. There is also lot of other hardcoded stuff like database connection settings and filesystem paths which must be changed when adapting those netbeans migration scripts for the OOo migration. The netbeans migration scripts do also contain some very netbeans specifc things which is of no use for the OOo migration like deleting certain users.

A subset of the netbeans migration scripts dumps data from a tigris mysql database into yaml files and another one reads those yaml files and imports the data into a kenai instance using ruby scripts and the kenai internal api. Additional there is a java program which uses date from gathered by using the AdHocQuery on the tigris database feature available for domain administrators on CEE websites like the previous netbeans.org website or the to be migrated OpenOffice.org website to get the current content for some migration-relevant tables and than incrementally updates a local copy of a tigris database created from an older collabnet dump.

The netbeans migration scripts exclude collabnet internal usernames which are marked with a special flag in the tigris database and maps those to a new "unmigrated-user". The netbeans migration scripts do convert usernames shorter than 3 letters my appending -nb to them.

After the users have been created in the kenai instance usernames which have been changed to new names are also changed in the bugzilla database.

The netbeans migration scripts do not completely address the problem of migrating derived roles, in this area additional work is being needed.

The migration of the "canconfirm" group membership of users to corresponding bugzilla permissions must be implemented from scratch by the OOo migration team, the netbeans migration did not do anything like that.

Creating serialization data for migrating projects, adding users to projects, defining roles for users in projects, assigning users to mailinglists for projects and downloadable files in projects is all done at once by the migration scripts.

There is a system administrator users "root" on CEE which must not be migrated.

There is a messages.properties file in the netbeans migration scripts which is used to define the text and subject for the migration mail send to the user and also the messages usually send by kenai for actions such as adding users to projects.

Note: The current active code for setting the password in the netbeans migration script HEAD revision sets just one fixed password for all users instead of generating a random one, the code which does generate a random one is there but commented out, must remember to change that before final migration.

The netbeans migration tools use a text file which contains data about projects like there old name, their new name, their old owners name, their new owners name and so on. There is also a text file defining the migration of mailinglists to a different project and or a different mailinglist name and a text file containing definitions for migrating issues. It is unclear how these files have to be created if their use in the OpenOffice.org migration tools would be the same. Most likely they will have to be created manually.

We also want to do incremental update of the tigris database. Getting the data for the incremental update by using the AdHocQuery CEE feature was done manually by the netbeans migration team and that manually saved HTML pages where parsed to update the database . We also automate that step with a shell script using curl.

Open Questions

When users are added to projects, roles are defined for users and users are added to mailinglists normally emails are send to the user notifiying them about the action that just happend. As we do not want to spam our users this should not happen during migration. It´s currently unclear whether sending this mails to the users is turned off by the netbeans migration scripts or what else must be done to prevent spamming our users during migration. Also sending the migration email with the new username and password must be turned off while experimenting with and developing the migration scripts on the staging site.

Can we get a site wide roles feature on kenai?

ToDos

Adapt netbeans migration tools for projects, users, roles, permissions and mailing lists to OpenOffice.org needs.
Find out how to create content for project/migrate* config files.
Extend migration scripts with some tooling to get CEE canconfirm group membership and to set corresponding permission in new bugzilla instance
Extends migration scripts to migrate domain admin priviledges.
...