m.vandun Posted November 8, 2016 Share Posted November 8, 2016 Hi, Since the latest patch, I again need to redefine the custom fields in the details screen. This seems to happen every time an update has been done and has started to consume a lot of time fixing this. Is there a reaseon why this is happening? Regards, Mark Link to comment Share on other sites More sharing options...
Martyn Houghton Posted November 8, 2016 Share Posted November 8, 2016 @m.vandun Mark This has happened to again as well. Cheers Martyn Link to comment Share on other sites More sharing options...
Martyn Houghton Posted November 8, 2016 Share Posted November 8, 2016 @m.vandun The workaround we used last time, was having to go into the Transalation setting and reset them, as the rest of the definitions where okay, it was just the labels that got corrupted. Cheers Martyn Link to comment Share on other sites More sharing options...
Guest riz Posted November 8, 2016 Share Posted November 8, 2016 Hi Mark and Marty, Thanks for reporting this issue, we are looking in to this issue, I will get back to you when I reproduce on our development instance. Thanks! Riz Link to comment Share on other sites More sharing options...
Martyn Houghton Posted November 8, 2016 Share Posted November 8, 2016 @riz Previous post may help with your replication process. Cheers Martyn Link to comment Share on other sites More sharing options...
m.vandun Posted November 8, 2016 Author Share Posted November 8, 2016 Unfortunately resetting the translation did not resolve this. When going to the custom field form you see the custom field with the default label, when opening the details you see the old (correct) label. Adjusting the named label and saving this does not change the name in the custom field overview. Mark Link to comment Share on other sites More sharing options...
Martyn Houghton Posted November 8, 2016 Share Posted November 8, 2016 @Mohamed Just to clarify when you refer to the latest release, is this one after SM v2.36.3 or do you mean that once we correct them in this new release, they should not get corrupted again by future release? Cheers Martyn 1 Link to comment Share on other sites More sharing options...
m.vandun Posted November 8, 2016 Author Share Posted November 8, 2016 This seems to solve the issue. Thanks Mark Link to comment Share on other sites More sharing options...
Martin.bowman Posted November 8, 2016 Share Posted November 8, 2016 @Mohamed I have checked the translations filtered on "ui.app.com.hornbill.servicemanager.requests.custom" and the translated labels are correct as we set them, however the labels still display incorrectly on the design form and also on the details form within a request. I have tried resetting the translated label and then re-keying and saving but this made no difference. Can you advise please. Link to comment Share on other sites More sharing options...
Martyn Houghton Posted November 8, 2016 Share Posted November 8, 2016 We and my colleague have not located the translation tab on the field properties and are entering in values, but they are still not being displayed on screen in the user app. Also are these label translation service specific now, rather than generic? Cheers Martyn Link to comment Share on other sites More sharing options...
Guest Ehsan Posted November 9, 2016 Share Posted November 9, 2016 Prior to Service Manager 2.36, Custom fields for Details section of each Request type (Incident, Service Request and etc.) within Services were generic (e.g. if you added a label called "Cost" in ServiceA, this was also presented in ServiceB). We have enhanced this area by providing the option to: Add Custom fields on a Service by Service basis and per Request type. In the example above, "Cost" will only be present in ServiceA and for requests that are raised against this Service. In ServiceB, you can create a Custom field called "Unit" and this will only be present in ServiceB and for requests that are raised against it. In other words, completely segregated. You could also open a Request type (i.e. Incident) and add a Custom field, which will then be present across all Requests of that particular type. This is to cater for scenarios where you intend to add a generic Custom field. Add Translations for different languages. Under this new approach, we will no longer need to maintain Application Strings such as "ui.app.com.hornbill.servicemanager.requests.customA" while I would like to use this opportunity to request if you could please refrain from updating these Application Strings through the Admin Tool so that we can maintain the data that was captured prior to this enhancement. Instead, when configuring a Custom field, you should see a tab called "Translations" where you can enter a translation for English and other languages. The value that is set in the "Translations" tab for the language that is defined against your Profile will be presented on the form. These Custom fields along with their corresponding translations are no longer referring to Application Strings and instead, the configuration of your Custom fields are held against each Service's record. There is one other point that I would like to stress here and in advance, I would like to apologise for any inconvenience that this enhancement has introduces to your operations however, there are challenges to adhere here. Custom fields were generic prior to Service Manager 2.36. Migrating these over across to all Services in your instance would continue to maintain the generic integrity of these although, if you were to edit Details section of ServiceB for example - to utilise this new enhancement, you would have to start off by removing this generic field prior to adding your own Custom label. This is more of a migration challenge rather than a problem. The migration of your Labels over to the Translations tab is currently under investigation however it has been mentioned above, if you open a Custom field and copy the content of "Field Label" into "Translations" tab, you should be able to see your Custom fields again. This enhancement was added to provide you with more freedom to customise your Services, while this promises to improve the association of Services to Requests and allow Service Desk users to capture relevant and appropriate information to progress requests. This also hugely takes into consideration the language capability of Hornbill, which will surely improve the interaction between end-users (i.e. Portal Users) and your business. Please bear with us, while we get this right. @Martyn Houghton and @Martin.bowman, we will get in touch with you ASAP to investigate your issues relating to this. Thanks, Ehsan Link to comment Share on other sites More sharing options...
Martyn Houghton Posted November 9, 2016 Share Posted November 9, 2016 @Ehsan Thanks for the detailed explanation. We currently have generic custom fields across all out services, i.e. there are around 10 fields we have on each of 100+ services. so at the moment we need to re-instate the generic labels for these, which from your description I presume is the Request Type scenario rather than the Service scenario? Cheers Martyn Link to comment Share on other sites More sharing options...
Guest Ehsan Posted November 9, 2016 Share Posted November 9, 2016 @Martyn Houghton, If you open an Incident record that is associated to a Service and add a Custom field, then this Custom field will be appended to the Details section of the Service's Request Configuration. If you open an Incident that is not associated to a Service and add a Custom field, this Custom field will be present on all Incidents. Under this approach, you can configure these Custom fields to be generic. I believe in your scenario, you may want to use this option. Link to comment Share on other sites More sharing options...
Martyn Houghton Posted November 9, 2016 Share Posted November 9, 2016 @Ehsan We have always used the View Details form in the Services under the Request Type to setup the custom fields. Therefore setting the fields here would they be specific to the Service? Also interms of setting generic ones per request type by setting them up on a request not linked to a service, will these be applied to all services, unless overridden? Cheers Martyn Link to comment Share on other sites More sharing options...
Martyn Houghton Posted November 9, 2016 Share Posted November 9, 2016 @Ehsan Ok, we worked out that we now got to go into every custom field (9 off them) on each Service (110+) to set the translation values, in order for the label to be displayed properly. It is good that labels now match the custom field definitions which are per service/request type, just that it would be good to have some form of migration process/sql to copy the current central value to the translation tabs as a starting point. Cheers Martyn Link to comment Share on other sites More sharing options...
Guest Ehsan Posted November 9, 2016 Share Posted November 9, 2016 @Martyn Houghton, Apologies for the delay in my response. We are preparing and working on a migration plan to address this issue, so that you do not have to add these Custom fields to your Services manually. I have been actively monitoring and working on this today and we consider this issue as our highest priority at the moment. Thanks, Ehsan Link to comment Share on other sites More sharing options...
Martyn Houghton Posted November 10, 2016 Share Posted November 10, 2016 @Ehsan Just wondering if there is a timescale on the availability of the migration script, as wondering whether to start manually correcting the labels or hand fire? Cheers Martyn Link to comment Share on other sites More sharing options...
Guest Ehsan Posted November 10, 2016 Share Posted November 10, 2016 Hi @Martyn Houghton, We have now completed implementing a solution and we are currently testing this. We believe if all goes ahead as expected, we should have a patch ready later on in the afternoon. Thanks, Ehsan Link to comment Share on other sites More sharing options...
Guest Ehsan Posted November 10, 2016 Share Posted November 10, 2016 Hi @Martyn Houghton, Please update to Service Manager 2.36.6, where we have fixed this issue. Meanwhile, we are working on improving the way Languages are handled within this feature. Thanks, Ehsan Link to comment Share on other sites More sharing options...
Martyn Houghton Posted November 11, 2016 Share Posted November 11, 2016 @Ehsan We have applied v2.36.6 this morning and that does seem to have reinstated out labels accross all our many services. Thanks you. Cheers Martyn Link to comment Share on other sites More sharing options...
Guest Ehsan Posted November 11, 2016 Share Posted November 11, 2016 That's great to hear @Martyn Houghton Link to comment Share on other sites More sharing options...
Lyonel Posted November 15, 2016 Share Posted November 15, 2016 @Ehsan, Although the patch fixed the problem for me (as mentionned by Martyn), all my colleagues cannot see the "translated" text... Any idea why? Link to comment Share on other sites More sharing options...
Martyn Houghton Posted November 16, 2016 Share Posted November 16, 2016 @Ehsan There appears to be a difference in the display of the translated label between browsers used. They appear to work fine in Chrome and Firefox, but are still displayig as Custom_X in Internet Explorer and Edge. Cheers Martyn Link to comment Share on other sites More sharing options...
Guest Ehsan Posted November 20, 2016 Share Posted November 20, 2016 Hi @Lyonel, Apologies for the late reply, I was away this past week. Are you referring to the text that is presented, if there is no translation for a label in any language either than English? Could you please clarify with a screenshot and example of the problem that you are referring to? Thanks, Ehsan Link to comment Share on other sites More sharing options...
Martyn Houghton Posted November 21, 2016 Share Posted November 21, 2016 @Ehsan, @Lyonel We are seeing some difference in behaviour between Chtrom and Internet Explorer, with the latter still seeming to have issues displaying the custom field label transaltions. @Lyonel Are you using a different browser to your colleagues? Cheers Martyn Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now