Important note Retirement of icTime and Retirement of biz on December 29th, 2023
Fix Work Logs (Warnings)
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.
Inconsistent Work Logs
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.
A "broken worklog" is a worklog which is not any longer in a consistent state. A non consistent state of a worklog can be reached when
- a worklog is moved from one project to another project using JIRA move Issue functionality
- the icTime project configuration for a project with existing and not billed worklogs changes
- JIra default worklog functionality is NOT disabled and worklogs are created using default JIRA worklog screens
- icTime is installed / enabled on a JIRA installation with existing JIra worklogs (similar to changing the project configuration)
Checking for broken work logs
Every time you run a report, IcTime checks all not billed worklogs from the result set for consistency. In case inconsistent worklogs are found a warning indicator is displayed.
Switch to the "warnings" tab to review the warnings in detail.
At least one or all of the following problems exist on the level of the work logs:
- Project reference in ictime worklog does not match project of issue (after moving a worklog between projects)
- Team & price list assignment (see Fix Work Logs (Warnings)) of the work log in ictime still point to the team of the old project.
- The work log might have assigned an activity type (see Fix Work Logs (Warnings)) that does not exist in the new project.
- The work log might have been created using a rounding rule (see Fix Work Logs (Warnings)) that does not exist in the new project.
- The work log might have been created using a Work Log Attribute (WLA) (see Fix Work Logs (Warnings)) that either does not exist in the target project or that is related to an activity type that does not exist in the target project.
All work logs with warnings will also be displayed in the list view and structured view of your report, and this also means that these views will show inconsistent data as long as the work logs are not fixed. If an issue with work logs has been moved from project A to project B, when looking at the summary of project B, you will see teams and price lists or activity types that belong to project A.
You can't charge work logs with warnings, but have to fix them before. See Charge Work Logs - Create Invoice.
Warnings
Go to the reporting screen and run a report for all projects (see Create Reports). If there are work logs with problems, issues and related work logs will automatically be displayed when you click on the "Warning" item in the navigation bar (the item won't be available if no work logs with problems are found):
From this view, you can either delete the work log/work logs, or try to "fix" it.
| Field | Description | Remarks |
|---|---|---|
 | Delete work log. | |
 | Repair work log. |
There is also the option to "automatically" fix all work logs, as far as this is possible:
Usually, JIRA restrictions regarding issue status are applied when editing a work log, you can't modify work logs for closed issues. However, in reports, those restrictions are not applied, and this also applies in case of fixing work logs.
Fix Work Logs
Correcting a work log requires that configurations regarding teams & price lists of old and new project are compatible, i.e. basically that
- the user who has created the work log is in a team with a valid price list for the date of the work log for both projects
- or the new project is configured not to use teams & price lists.
If this is not the case, configuration of the new project needs to be modified.
Correction Possible
If both project configurations are completely compatible, i.e.
- the user who has created the work log is in a team with a valid price (for the date of the work log) list in the new project
- the activity type exists in old and new project (or activity type s have been deactivated at the time the work log had been generated and still are deactivated)
you can just correct the work log.
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).
| Field | Description | Remarks |
|---|---|---|
| Work Log | Base information from work log, like date, summary, ... | |
| 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). It does not matter if ictime is currently configured not to use activity types (see Activity Types), you always can choose a new activity type according to the activity types available for the new project (see Project Activity Types). This also might be "–" (none). | 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
If both project configurations are not compatible regarding teams & price lists, you can't correct the work log but first have to change the configuration of the new project. This is the case if
- the new project uses teams & price lists and
- the user who has created the work log is not part of a team in the new project or
- the user is part of a team in the new project, but there is no valid price list for this team for the date of the work log.
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.
Fix Multiple Work Logs at a Time
Before starting to fix work logs one by one, you should first try to use the respective "batch" functionality that automatically fixes all work logs where this is possible. Click the "Fix Work Logs" button in the navigation:
If there are work logs that do not require any manual intervention to be fixed (for details on conditions to be covered, see explanations above), they will be displayed in a list and you can fix them with just one click:
The screen will also tell you if there are work logs that can't be fixed automatically. In this case, after running the automatic action, you would need to review the "Warnings" screen again and would need to fix remaining work logs manually.
Specific Issues for Work Logs with Work Log Attributes WLA
If you are working with Work Log Attributes (WLA), moving isues between different projects in JIRA might cause similar problems like the ones described above. There are two scenarios:
WLA Type A (Activity Type)
If you have moved an issue with work logs that have a specific WLA of Type ACTIVITY TYPE between two projects, the following can happen:
- The target project also has the same activity type assigned. Nothing has to be done and no problem occurs, as the activity type-WLA relation exists in both projects, original project and target project.
- The target project does not have the same activity type assigned. This will lead to the problem already described above, the user will have to select another activity type (or in case the new project does not use activity types at all, the activity type will be deleted as part of fixing the work log). When fixing the work log, the WLA value will be deleted, because the original activity type this WLA was related to does not exist any longer after fixing the work log.
WLA Type P (Project)
If you have moved an issue with work logs that have a specific WLA of Type PROJECT between two projects, the following can happen:
- The target project also has the same WLA assigned. Nothing has to be done and no problem occurs, as the project-WLA relation exists in both projects, original project and target project.
- The target project does not have the same WLA assigned. When fixing the work log, the WLA value will be deleted, because this WLA does simply not exist in the target project.