Ravenbrook / Projects / Perforce Defect Tracking Integration / Issues
Perforce Defect Tracking Integration
| Title: | Migration of jobs to Bugzilla fails if a job is owned by a non-existent user |
| Status: | closed |
| Priority: | essential |
| Assigned user: | gdr |
| Product: | p4dti |
| Organization: | Ravenbrook |
| Description: | If you have jobs in Perforce that are owned by a non-existent user, or a user who's been deleted, then the P4DTI can't migrate those jobs to Bugzilla. You get the following error message: Bugzilla module error: (P4DTI-514X) There is no Bugzilla user corresponding to Perforce user 'spong'. |
| Analysis: | When the replicator comes to apply the field map, it tries to translate the Assigned_To field using the strict version of the user_translator (with allow_unknown = 0). This fails before prepare_issue_advanced has a chance to do anything with the less strict version of the user_translator (with allow_unknown = 1). You can work around this problem edit jobs owned by non-existent users so that they're owned by somebody else (we could assist this by adding this check to the check_jobs script). But I bet this will come up a lot. Possible solutions: 1. Set allow_unknown = 1 during migration. All unknown users end up as the special Bugzilla user in Bugzilla; when we refresh we get the P4DTI user. Information lost. 2. Leave it as it is; stop with an error we find an unknown user. Force the admin to either change the job or create a user in Bugzilla. 3. We could create Bugzilla users for all these unknown users during migrate_users (creating them disabled?). But we don't know which fields have users in them, which we don't. 4. Check this case during check_jobs.py; force the admin to make the User field valid for all jobs. (Admin could add user to Perforce but in general they don't have any licences left.) Not good because we don't know which fields to check at this stage since they haven;t yet written translate_jobspec. 5. Split the migration steps into (a) a translate jobspec step and (b) the migration step itself. Then at step (b) we would know which fields were user fields and then we could apply solutions 3 and 4. |
| How found: | manual_test |
| Evidence: | Found during testing release 1.3.0. |
| Observed in: | 1.3.0 |
| Introduced in: | 1.3.0 |
| Test procedure: | none |
| Created by: | gdr |
| Created on: | 2001-11-27 17:43:35 |
| Last modified by: | gdr |
| Last modified on: | 2001-12-10 20:00:01 |
| History: | 2001-11-27 GDR Created. |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 24576 | closed | 2001-11-29 18:22:38 | gdr | Described how to cope with non-existent users in Perforce when migrating to Bugzilla. |
Generated at 2008-07-09 03:00:41 by $Id: //info.ravenbrook.com/infosys/cgi/issue.cgi#430 $
Copyright © Ravenbrook Limited. This document is provided "as is", without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this document. You may make and distribute verbatim copies of this document provided that you do not charge a fee for this document or for its distribution.