When the Label of a field in the FORM section is different from the name of the field and a rule is not fullfilled at commit-time, the error shows the name of the field and not the name of the label. However the user can not find a field with that name because on the forms only the Label-name is showed.

E.g.: if the "Found In" field required and the label for the field on the form has been set to "Build Version" then the error shown when the field is not set becomes: "TF20012: Field "Found In" cannot be empty". There is no field with a such a name on the form.

I am assuming that you are using "Build Version" as label in the Form section for field "Found In". If "Found In " field is required and if you don;t populate with some value and attempt to save then in the error message you have "Found in" cannot be empty and you expet "Build Verion" cannot be empty. This is by design. The labels for just for the display and nothing to do with fields. In error message we get field names.

Thanks

Sagar

Sagar Sura wrote:

This is by design. The labels for just for the display and nothing to do with fields. In error message we get field names.

Then the design needs to be changed.

You are thinking like a programmer and not listening to your users or thinking about how the system is going to be used. Microsoft has developed an extensible system but forgot that the error reporting has to match it.

It makes absolutely no sense what so ever to display in the UI an error message talking about a field the user cannot see. So you are forcing an error message on to the user that the user cannot do anything about.

For logging purposes your design makes sense as the the one going through the logs would be the admin wwho set up the process and the fields. But when a user is using Team System then the error message MUST be in the form that he can understand.

-- Robert

Robert,

I totaly agree !

Peter

Here are the reasons why we do not specify the label names in the error message:

- The field in problem may not be displayed in the form and hence may have no label.

- The same changes to workitem could be done in Object model, and we won't have any label name there and will have different message. We would need to "convert" that message in UI.

I know these issues can be mitigated, so I'll raise a bug on this issue and hopefully the experience would be better in future release. Thanks much for your feedback.

Naren Datha - MSFT wrote:

The field in problem may not be displayed in the form and hence may have no label.

Yes. Possible but then there is a more serious problem because how is the user to be able to correct the value if there is no UI. You just totally confused the user. I realize that this is not the fault of TeamSystem but of the person who modified the process template and added a field so it got a value it was not allowed to have.

Naren Datha - MSFT wrote:

The same changes to workitem could be done in Object model, and we won't have any label name there and will have different message. We would need to "convert" that message in UI.

I understand that in some cases you dont have direct access to the value you need to display and I'm glad you see the need to convert the value.

Naren Datha - MSFT wrote:

I know these issues can be mitigated, so I'll raise a bug on this issue and hopefully the experience would be better in future release.

Its the right thing to do.

Thanks

However there is a workaround for this. You always can change the field name and match it with your label in form section. In the error messages you can get what you want. You can use WITFIELDS command-line utility to rename a field

Thanks

Sagar

True but that only works in a limited number of cases where the name would be ok. In his example he needed to call it Build Number rather than Found In. The names just aren't close enough.

I second the need for being able to configure the error message of required fields. Renaming the fields is just not flexible enough. It really impacts the projects and their usability, especially if you go the route of developing something custom.

Maybe a new attribute for the work item field (i.e. alias), that can be used in the displayed error message if defined?