Gareth Cantrell

Don't mind me - I just found the Supported Languages setting

We have a requirement to add Japanese translations to some of our services and catalog items, however Japanese is not an option in the translation settings. Can we please add this as an option. Thanks, Gareth

Alternatively, please re-instate the "Entity : Services : Created/Updated" event source in the webhooks so we can extract and publish this information to a wiki when changes are made to the services.

We would like to request some finer-grained permissions for the service portfolio. Currently, the built-in Services Manager role has the following permissions: View Service Records Create Service Records Edit Service Records Delete Service Records Manage Subscriptions There doesn't appear to be any permissions controlling access to the Priority Levels and SLAs. This means that even though I have created a "Services User" role, with only the "View Service Records" permission, anyone with only this permission still has access to edit, delete and create both existing priorities and SLAs. Additionally, there are no permissions to restrict who can create bulletins or FAQs against a service. We would like to give our agents read-only access to the service portfolio so they can see the details and custom fields we carry which hold important contextual information, however, we cannot allow everyone to have free reign to edit, delete and otherwise change the priorities, SLAs, bulletins and FAQs.

We have noticed an inconsistency with the advanced search filters in the Request List. If we filter on "Source" is "Email", the request list is correctly filtered. However, if we filter instead on "Source" is not "Email", then the filter is ignored and returns all the requests.

Thanks @NeilWJ The workaround works for me, although I ended up using the API to manually create my webhook earlier.

When you click the "Create Webhook" button, after filling in all the details, nothing happens. Editing and saving an existing webhook works fine, but I am unable to create a new one.

We are unable to create new webhooks. When clicking the "Create Webhook" button, nothing happens. Looking a the browser Developer Console, there is no network activity initiated when clicking the button.

@CraigP I had a similar issue and it requires that either your service has a default BPM set, or that you explicitly set the bpmName attribute in your request. The API does not lookup and use the BPM set against a catalog item.

When using the "Copy Request" functionality, request specific fields (such as h_implementation_plan, h_backout_plan, etc on Change Requests) are ignored. I looked through all the "app.request.copy.*" settings in service manager, and there are no options to enable the copying of type-specific fields. From what I can see this prevents effective copying of request types other than Incident and Service Request. Could we please include an option that allows copying of the type-specific fields for Change Requests, Problems and Known Errors?

Could we get an update on when this fix will land? I had been hoping it would've dropped with the latest update, but it appears not to have made it in.

@Steve Giller yes, "Open URL" action works as expected, its just in the Popup action that the variable substitution doesn't work. In my example, I passed the parameter "igu=1" to Google which allows their page to be embeddable and it definitely works as an embeddable page (see my 2nd screenshot).

When creating a custom button using the "Popup" action, any variables added to the URL are not substituted when the button is activated. For example, trying to open a Google search on the request summary in a popup results in a search for "[[h_summary]]", rather than the actual summary of the request. See below screenshots for examples: 1) Custom Button definition: 2) Result of variable substitution:

+1 for this please! I struggled for ages with this one before realising that either 2 calls were needed or the external system had to have the bpm name hardcoded (not an ideal scenario!)

We have an issue where a request has been placed on hold, waiting for customer. If the customer responds via a timeline update, the request correctly comes off hold. However, if the customer responds via a comment to an existing timeline update, the request stays on hold and the owner is not notified of any activity. How can we ensure to force a request to come off hold in the 2nd scenario (when a comment is added rather than a full timeline update)? Thanks, Gareth

We are busy with the process of importing all our suppliers and contracts into Hornbill, however we have a number of contracts with suppliers that are facilitated by resellers. At present, there is no way in Hornbill to show this relationship, however I did see a roadmap item for this that was accepted last year, and we'd like to +1 this for consideration.

+1 for us too. On both technical and business owner but also on the additional custom fields. We had all this information and more in our previous service catalogue and had to lose it all in the migration to Hornbill due to the limit on available fields.

When changing the service connections for a service via the UI, new records are being created in the database. In the below screenshot from "Database Direct", the original records for service id 13 are h_id's: 7, 8 & 9. Selecting the "All" button for all permutations in the service has caused additional rows to be created. This has the downside of not allowing connections to see the timeline or comment as expected when we've supposedly allowed collaboration. I have had to manually delete records from the database using the "data:deleteRecord" API to get this working as expected, so that the database looks like the 2nd screenshot below. { "@service": "data", "@method": "deleteRecord", "params": { "application": "com.hornbill.servicemanager", "table": "h_itsm_service_connections", "keyValue": ["9","597","600","7","595","598","8","596","599"] } } Table1: Incorrect Table2: Correct - after running "data:deleteRecord" API

+1 - we had this functionality in our previous portal and are definitely missing it in Hornbill.

+1 for us - this would be super helpful

Is there anything that can be done to fix this? Maybe use a custom attribute on the user account for SAML? Those at least have 128 characters. There is definitely no way we can reconfigure over 3000 accounts just so their UPN's fit into 64 characters.

I think I found the issue. The setting app.itsm.progressiveCapture.newRequestFromEmail had no value, so the default IC "new request" was being used (and by default, I mean the setting: app.itsm.progressiveCapture.newRequest = "new request") This then did a switch capture to the "new service request" IC which in turn performed a switch capture to the IC configured to the catalog item. The IC for "new request" is "Co-worker search" -> "Request type details" -> "Select service" -> "branch on request type" -> switch capture (to "new service request" in this case) The IC for "new service request" is: "Co-worker search" -> "Select service" -> switch capture (to "IT - Service Request") The IC for "IT - Service Request" is: "Request details" -> "Attachments" I set the app.itsm.progressiveCapture.newRequestFromEmail setting to "new service request", bypassing the generic "new request" IC and now all is working as expected.

@James Ainsworth We've looked at the customer portal. Unfortunately, we will not be allowed to present that to any partners as it does not follow our approved guidelines for colour schemes and is not customisable (for example, all the service icons are a blue-ish colour). Additionally, all our partners are already part of our core SSO and already imported as basic users (as we could not have gone live without offering them support). Aside from that, having the ability to control widget visibility by group would also allow us to selectively show widgets to different groups of employees.

Something we would find very useful is the ability to have subscribers for portal widgets, in much the same way as we have for services. We have a number of 3rd parties who work with us and require access to our portal to raise requests and would like to only show specific information to these users. For example, we have a links widget which shows links to internal sites which ideally should be hidden from these users. We also have some "buttons" in a links widget which allows users to navigate to our Facilities and HR domains and would also like to restrict visibility of these. Having the option to subscribe certain groups of users would allow us to effectively hide widgets such as these from users not in the correct Company/Department/Group/etc.

@James Ainsworth thanks for your response. We don't have anything specified in that setting. What happens is when we click "+ Raise Request", we go through the default IC as mentioned, which asks us for the service and catalog item. Even after selecting this correctly (i.e. using exactly the same service & catalog item that is configured in our routing rule template), it is not attaching to the workflow specified in that catalog item.