Gareth Cantrell

The latest ServiceManager release, 3251, which should've fixed the translate button showing is not working as expected (PM00184918). The translate button is now showing for all requests raised in en-US and viewed in en-GB (and vice-versa).

The Autotasks tab in Service Manager is also showing Workflows. Could this please be rectified. (I have already use the developer mode empty cache and hard refresh to no avail)

Even better, if only the display values are stored, the checkbox field in the details screen doesn't show any data, even though the underlying field has the simple list display values stored.

Here is a screenshot of the custom field values from the latest change requests (so you can see that its not just me going mad):

+1 (again)

This is a change request, so users get to edit the details until they're ready to submit the change for approval. We use the values in this particular field to make decisions on approvers and whether or not to raise linked requests for the appropriate service desk to send out targeted comms. This field is backed by a simple list in both the capture form and the request details form (the exact same simple list) and we have a node in the workflow which forces the raw value from the capture field immediately after creation. However, when the user subsequently edits this field in the request details section, it appears that the system will randomly store either the simple list raw value or display value or sometimes both raw and display values in the custom field. Sometimes the field is stored with brackets [] surrounding the selected values, and sometimes without. If this field was for information purposes only, I could live with the inconsistencies, but we use it for decisions in the workflow and we have had a number of issues where things have been missed or incorrectly assigned because of this.

Bump - can someone from Hornbill please confirm this? Do we need monitor every update via webhooks and API calls to ensure consistency in stored field values?

Why would a basic user get an error message when trying to post an update to their own request via the portal? There is only this user affected that we are aware of however it is still concerning that a basic user cannot update their own request without requiring full user rights!? User has the standard roles of all other basic users:

The Label fields accept wiki markup rather than HTML (https://docs.hornbill.com/esp-fundamentals/reference-guides/hornbill-wiki-markup)

@James Ainsworth They'll be using the same services, but a limited subset. For now, we've given them a direct URL to the simplified translated page and included a large link in the main home page that redirects them back to the translated home page if they find themselves there by accident. It's not the greatest user experience, but it avoids them being stuck in a page they cannot understand.

@James Ainsworth this appears to be setting the colour schemes, fonts and the link from the logo, rather than a separate home page. I may be missing something, however I also don't want to break a live system by experimenting too much.

The customer feedback popup translations keys are showing in the translations admin screen however, the translations ONLY show on the initial invocation of the feedback popup. Subsequent reloads consistently revert to the default English. EDIT: this only happens if the page is refreshed.

Another update on this - I've just received another "Incident" where the IC details "raw value" was retrieved in the workflow and saved to the custom field. When the user updated this field from the request view (Details panel), the raw values were replaced by the display values - as I mentioned previously, we cannot control edits in the Details panel from the workflow, so we now sit in a dilemma where the wrong values are now stored in the field. The behaviour of checkboxes seems entirely inconsistent and if this is not going to be fixed anytime soon, can someone please let me know how I can maintain consistency in these fields as we rely on the values for decisions later in the workflow.

+1 EDIT: actually, can I +100 here please - I've lost count of the amount of times I get eye-rolls (this is the polite term) from colleagues when I tell them they cannot get notifications when they're members on a request

We are doing some final testing before rolling out translations, and the following issue just cropped up: If a user, whose profile language is correctly set to their home language (in this case Japanese), replies to a system notification, the timeline is updated by the System Autoresponder, but in the system default locale, so we are unable to translate the text in-app. I was expecting to see the translate button to the right of the customer button, but for updates via email, this is not happening. Is this something that could be looked at? @James Ainsworth FYI