...
When moving issues with work logs - created or updated with ictime - to a different project in JIRA, this will lead to inconsistencies in ictime data. This problem needs to be fixed manually.
...
ictime relies on JIRA work logs and enhances JIRA work logs with additional information like an activity type, a rounding rule or a relation to a team/price list. As JIRA is not "aware" of ictime and ictime can't modify base operations in JIRA like moving an issue, ictime data will get inconsistent when you move an issue with work logs - created or updated with ictime - to a different project in JIRA. This issue will now belong to a new project (and would be displayed correctly in ictime - Reporting, My Timesheet), but team & price list assignment (see Project Teams) of the work log in ictime would still point to the team of the old project - ictime does not even know that you have moved the issue. In addition to the team problem, you might also have a problem with activity types (see Project Activity Types), as the work log might have assigned an activity type that does not exist in the new project.
...
| Field | Description | Remarks | ||
|---|---|---|---|---|
| Work Log | ||||
| Old Project | Project key of the original project (where the work log had been created before the issue was moved in JIRA). | |||
| New Project | Project key of the new project. | |||
| Issue | Issue key. | |||
| User | User who has created this work log. | |||
| Old Activity Type | Activity type used | If the original work log had been created without activity type (historic data or activity types deactivated in ictime at the moment you have created this work log), "none" will be displayed here. | ||
| New Activity Type | Depending on the activity type configurations of old and new project, you might have to choose a new activity type (if the activity type of the work log does not exist in the new project).
| If the activity type does not exist in the new project, and changing the activity type of the work log is not okay for you, you need to assign the missing activity type to the new project first (see Project Activity Types). If there is no suitable activity type in the new project, but you do not want to create a suitable one, you also might choose the option "none", i.e. there will be no activity type assigned.
| ||
| Old Team / Price List | Team and price list for the original work log. | Might be empty if the original project had been configured not to use teams & price lists at the moment when the work log was created/updated (see Project Teams). | ||
| New Team / Price List | Team and price list the user is assigned to in the new project. | You can't correct the work log if
If the new project is currently configured not to use teams & price lists (see Project Teams), there is no problem, regardless of the configuration for the original work log. In this case, you can always repair the work log. Price information from the original work log will be lost in this case. | ||
| Old Rounding Rule | Rounding rule (of the original project) applied to the work log when created/updated. | |||
| New Rounding Rule | Rounding rule (of the new project) that will be applied to the work log when you repair the work log. | There is nothing to configure. The new rule will automatically be applied to the work log. |
Correction Not Possible - Further Actions Required
...
In this case, you will get e.g. the following error message when you try to save:
As the user in this case is not assigned to any team of the project (with a valid price list), but the project itself has been configured to use teams & price lists, you can't correct the work log. You need to assign the user to a team in the new project and ensure that there is a valid price list (see Project Teams and Project Team Price Lists). Once done this, you can try again and now will be able to correct the work log.
...