In setting up a customized value provider with a javascript based solution, you also define a list of dependencies (attributes) on the attribute for which a value is being calculated or validated by the value provider. It was discovered that in one particular case, the Owned By attribute has "category" and "target" as OOB or hidden dependencies defined under the covers. This was needed so that when the Filed Against (category) or Planned For (target) field is changed, the Owned By list must be recalculated, which is handled by some internal value provider logic. However, the custom value provider ALSO runs when either of these two attributes are updated, regardless of what dependencies are defined in the Eclipse UI Configuration Data -> Work Items -> Types and Attributes section. There are cases for which the custom value provider is not desired to run, and there is no way in the javascript to be able to tell which dependency attribute fired the custom value provider. This enhancement request is to ensure that a custom value provider is only run for the dependencies that are configured in the Eclipse UI process configuration. The underlying product code should still run whatever code it needs to based on it's own internal dependencies.
Use case:
A custom calculated value provider was written that would automatically assign an Owner to a work item, based on the Filed Against (category) chosen by the user. The user requirement was that they wanted the Owned By field to be updated dynamically when the Filed Against value was set, therefore the custom calculated value provider was the optimal choice since a followup action server extension only runs at Save time. The custom calculated value provider was then added to the configuration of the Owned By attribute, and the Dependencies was set to just "category". This all works great as-is. However, the customer's use case included the scenario where a user wanted to override the Owned By with a different person, so they manually set the Owned By field to someone else. Then they went and set the Planned For iteration to some value. However at this point, the Owned By field was dynamically reset. This is because the custom value provider ran again, and performed it's logic to set the Owned By based on the current Category chosen. This is an undesirable effect. Even though the Eclipse UI only shows "category" as a Dependency, the custom value provider also ran when the Planned For field was updated. This was discovered in testing based on the Case referenced above, where under the covers, both "category" and "target" are fixed dependencies. I would like to only see my custom value provider run on the Dependency attributes I configured in the process configuration.
The side effect of this custom value provider running when Planned For is updated has become a number of our customer's highest pain points.
Who benefits:
Any environment where a custom value provider is specified on the Owned By field.
Our team wastes time every sprint with unnecessary overhead when we move items to the next sprint and update the "Planned For" field. Items get assigned to the wrong owner when this happens they fall off an individual's view if we are not meticulous about monitoring it and changing it back.
This is a huge time sink and prone to human error. A fix to this would be greatly benefit us and others!
This is a huge pain point for the P / Z Systems teams, and it would be of significant value to fix this!