When a user changes a field value on which the values of other fields depend, some dependent values may need to be corrected.
This can happen if:
When a user changes the value of a field, and the value in another field becomes invalid as a result, the latter field (we call it the 'dependent' field) is reset to its default value the next time someone updates that artifact.
For example, picture a tracker called 'Interior decoration' in which, if the Color scheme field is set to Warm, the Carpet color field can be set only to Red, Orange or Yellow. Red is the default value.
User 1 sets Color scheme to Warm and Carpet color to Yellow.
User 2, after consulting the client, comes in and changes the color scheme to Cool. Now the allowed values of Carpet color are Blue, Gray and White, with Blue as the default. But the actual value is still Yellow, which is now invalid. It's up to the user who is updating the artifact to choose a new color from the new set of valid colors. If the user doesn't make a choice, TeamForge automatically changes the value of Carpet color to Blue, because that's the default value when Color scheme is set to Cool.
When you restructure a hierarchy of dependent values in a way that leaves invalid child fields in multiple artifacts, each of those artifacts must be fixed the first time a user edits it.
For example, in the artifact room1, User 1 has set the Color scheme field to Warm and the Carpet color field to Red. Suddenly User 2, the project manager, realizes that red is a terrible color for carpeting. User 2 changes the tracker settings so that Carpet color can be set only to Orange, Yellow, or Maroon.
The next time User 1 comes back to the room1 artifact, TeamForge warns that the field value is in an inconsistent state. If the user tries to edit the specific field that is inconsistent, changes to the artifact cannot be saved until the user selects one of the new allowed values for that field.
If you change the regular expression that governs what content is allowed in a text field, each affected field must be fixed the first time a user edits it.
For example, imagine that your 'Interior decoration' tracker includes a text field in which users can record the telephone number of a carpet installer. You set up a validation rule like [(]\d\d\d[)]\s\d\d\d[-]\d\d\d\d to ensure that only standard U.S.-format phone numbers can be entered.
The tracker has been in use for a week when you realize that email would be a better way to communicate with carpet installers. You change the validation rule to something like \b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b, to ensure that users will enter an email address.
The next time a user tries to update an artifact with a telephone number value in that field, TeamForge warns that the field value is in an inconsistent state. If the user tries to edit the specific field that is inconsistent, changes to the artifact cannot be saved until the user enters a value for that field that matches the new validation rule.
If you delete a field that contains values that another field's values depend on, the dependent field becomes a standard single-select field on its own. No correction is needed.