Custom Fields corruption

[Martin.bowman]

*** URGENT ***

Hi

I have been working on our Services adding custom fields to the Request Configuration > Incident > View Details Form in the order below. This was all ok on Monday when we went live and on Tuesday but now appears to be corrupt. Some fields are now duplicated and out of order, so a free text field is now a drop down with the label not corresponding to the contents of the drop down. This appears to have happened after the latest update was applied to Service Manager on Tuesday evening.

Please can this be looked at and addressed as a matter or urgency as I still have a large number of services to complete, I would also rather not have to revisit those already completed.

 

Order of Custom fields as created

Third Party Reference         Single Line text
Third Party                          Drop Down
Development Reference     Single Line text
Development Type              Drop Down
Version                                Drop Down
Assignee                             Drop Down
Assignee Status                  Drop Down
Condition                             Drop Down
Hosted Service Impact         Drop Down
Customer Reference           Single Line text

 

Custom Fields now displayed (see attached document)

Thanks

Martin

MoreDetails.docx

[Hornbill Staff DR]

Hi Martin,

 thanks for your post.
How many Services have you configured to date, and do each of these services contain all of the fields listed above, or are certain fields only relevant to certain services?

Thanks,
Dan

[Martyn Houghton]

We currently have 110 services, which is growing about 5 a week as the moment whilst we are adjusting post go live. All 110 of them have these custom fields, as they are generic to all our services at this time..

See post below suggestion of splitting custom fields between generic ones apply to all request types and those which are service specific, in relation to their display on the Request List screen.

Cheers

Martyn

 

 

[Hornbill Staff DR]

Hi Both,

Taking one example from the information provided above, although the field "Development Reference" appears twice, interrogating each of these fields shows that one is pointing at "( relatedEntityData.record.h_custom_c)" and the other is pointing at "( relatedEntityData.record.h_custom_d)" .

There only seems to be a duplication of field labels.

If you amend the field label using the translation string: ui.app.com.hornbill.servicemanager.requests.customD to "Development Type" (which is what I believe you want it to be) then this should address your issue.

Currently its not possible to amend the field labels via the User App once the field has been created (I have requested this be Changed), but we do have access via Hornbill Administration through Home > Service Manager > Translations and filter on "ui.app.com.hornbill.servicemanager.requests.custom".

I hope that helps,
Dan

[Martyn Houghton]

Dan

The data we have transferred and already populated is remains in the correct custom  fields, as does the field definitions and lockups for the fields.

This issue is the duplication of the h_custom_c we use for development reference which now appears for both h_custom_d as well, which then has the affect of pushing down the following custom fields, so the labels are all one out from the actual field that hold their data and the last custom field label is then lost.

We have made the changes in Translation and that appears to have resolved the issue at this time. However we are concerned that it is not clear what the root cause of this was.

Also we are a bit confused how this work around resolved this issue as we understood the labelling of the custom fields was service specific or has this been a recent change?

Cheers

Martyn