|
a/Allura/docs/migration.rst |
|
b/Allura/docs/migration.rst |
|
... |
|
... |
| 39 |
is ensuring that users referenced in the import JSON are available in Allura.
|
39 |
is ensuring that users referenced in the import JSON are available in Allura.
|
| 40 |
If, during import, some user does not exist, corresponding field in a ticket will
|
40 |
If, during import, some user does not exist, corresponding field in a ticket will
|
| 41 |
be set to Nobody/Anonymous.
|
41 |
be set to Nobody/Anonymous.
|
| 42 |
|
42 |
|
| 43 |
It oftentimes not possible or plausible to ensure that all submitting users have
|
43 |
It oftentimes not possible or plausible to ensure that all submitting users have
|
| 44 |
account on SourceForge, but it is usually more important to make sure that
|
44 |
account on the forge, but it is usually more important to make sure that
|
| 45 |
assigned-to users do have. Assigned-to users are usually more closed set, like
|
45 |
assigned-to users do. Assigned-to users are usually a smaller set, like
|
| 46 |
members of your project, so it's good idea to ask them to register SF.net account
|
46 |
members of your project, so it's good idea to ask them to register an account
|
| 47 |
before performing import.
|
47 |
before performing import.
|
| 48 |
|
48 |
|
| 49 |
Another common issue is that username in original tracker and in SF.net do not
|
49 |
Another common issue is that username in original tracker and in the forge do not
|
| 50 |
match. Import service provides ability to specify user mapping to overcome this.
|
50 |
match. The import service provides the ability to specify user mapping to overcome this.
|
| 51 |
For example, you can specify that user "john" as appearing in JSON should be
|
51 |
For example, you can specify that user "john" as appearing in JSON should be
|
| 52 |
translated to "john2" in SF.net. Mapping should be prepared in the form of JSON
|
52 |
translated to "john2" in the forge. Mapping should be prepared in the form of JSON
|
| 53 |
dictionary, e.g. ``{"john": "john2"}``.
|
53 |
dictionary, e.g. ``{"john": "john2"}``.
|
| 54 |
|
54 |
|
| 55 |
Other issue is extra ticket fields appearing in the original tracker. Allura
|
55 |
Other issue is extra ticket fields appearing in the original tracker. Allura
|
| 56 |
tracker by default support small number of generally usable fields. More fields
|
56 |
tracker by default support small number of generally usable fields. More fields
|
| 57 |
can be created as "custom" ones. Import service has the to automatically create
|
57 |
can be created as "custom" ones. Import service has the to automatically create
|