Hornbill Staff DR

Hi Prathmesh,  thanks for your post. Every item of text in both the Customer Portal and Service Portal is translatable. While this gives us the ability to translate the text into other languages, it also gives us the ability to define our own English translation, effectively changing the terminology we want to use. The "Translation Strings" (as we call them) are located in two areas of Hornbill Administration. Firstly, all the strings relating to the Portal Home page and stored in Home > System > Manage Portals > Translate. You'll recall from the webinars that Hornbill Service Manager supports two portals, and this area stores the strings for both the Service Portal and Customer Portal landing page. To help find the strings that are relevant to the portal you are setting up, use one of the following in the quick filter: To show only Customer Portal Translation Strings use: anonymous.portal.core To show only Service Portal Translation Strings use: anonymous.serviceportal.core Secondly, everything in what we call the "My Services" page (the page that you're presented with once you have logged into the portal) can be translated via Home > Service Manager > Translations. To show only Customer Portal Translation strings use: guest.com.hornbill.servicemanager.portals.portal To show only Service Portal Translation strings use: guest.com.hornbill.servicemanager.portals.servicePortal To amend a particular translation string, click on the text in the column named "Translated" and you will be able to edit the text. We have a weekly scheduled webinar that includes the fundamentals of Portal Customisation. If you feel you may benefit from an overview it may be worth registering here: https://wiki.hornbill.com/index.php/Hornbill_Webinars#Timetable The relevant wiki documentation relating to the Portals can be found here: Self Service features overview: https://wiki.hornbill.com/index.php/Self_Service Customising the portals: https://wiki.hornbill.com/index.php/Customising_Self_Service Hope that helps, Dan

Hi Keith, presently we work with both build numbers and version number for the Service Manager Application. In the future it is likely that we will move to using only build numbers. Just to outline the current state of play; Build 883 relates to Service Manager Version 2.36.6. The latest release available on live is build 889 (SM Version 2.36.8). Service Manager 2.37 is being prepared for release and should be available towards the end of the week but unfortunately the fix for the defect mentioned in my previous post didn't make the cut but is lined up for inclusion in SM Version 2.38. Dan

Hi Keith,  that's correct, it shouldn't matter and all request timeline updates should affect the last updated date. I suspect this is a defect which is why Dave wanted to know the source of the update as it will assist in him inspecting that area of the application to understand if it is doing what it should when this type of update is added to the timeline. I can actually see there is a defect recently resolved by dev "When updating a request timeline via the portal, or when commenting in any version of the app, the last updated date is not updated" which I would expect to see released in Service Manager 2.38 Dan

Hi Tina,  Having reviewed the log files and spoken with development, I can confirm that this has indeed been fixed and pending release. I'm currently awaiting an update on when this fix may be made available but we will update you as soon as we know. Dan

Hi Tina,  Looking at the screen shot provided it seems that this is an issue with the particular BPM operation. I believe this has already been reported and dev are aware of the issue but we will review your log files to confirm the exact reason for the BPM failure. Dan

Hi Both,  I understand that development are aware of this issue and are working on a fix. As you have already identified this issue is limited to Internet Explorer. Where possible, we would advise using an alternative browser such as Chrome or Firefox. Dan

Hi Mark,  Martyn is on the right track. This particular error "Stage Checklist validation failed", means that the workflow reached the end of the stage and found that there were mandatory checkpoints within that stage that had not been marked. Looking at the screenshot provided, there is a checkpoint (pink node) that can be bypassed in a particular scenario. I have highlighted this in the screen shot. A stage checkpoint should only be set as mandatory if it cannot be bypassed within that stage. You can manage the stage checkpoints by clicking the button towards the top left of the design canvas (identified by the tool-tip "Manage Current Stage"). Dan

HI Derek,  even though you have defined your Priorities, Response and Resolve times with in the appropriate tab, the actual timers are started and stopped by the Business Process workflow that is associated to your request. The following wiki page https://wiki.hornbill.com/index.php/Set_up_Service_levels specifically the section "Implementing my Service Levels" is the section that eludes to this. Your earlier post: leads me to believe that the workflow you are using against your Service Requests does not contain nodes to start the desired response and resolve times. I would first suggest the following:  Identify the Workflow that you are using for the Service against which the request is raised (where the SLA indicators suggest "Not in Use") Go to Hornbill Administration and look at the workflow design. Identify if you have automated operations in place to start and stop the response and resolve timers. If after looking at your workflow design you still aren't sure if they're there or not, download the workflow definition (by using the button towards the top right of the canvas) and post it to this thread. We can then take a look and see how its configured. Thanks, Dan

Hi Derek,  I can't see anything untoward in the log. Have all imported Basic Users been effected by the issue. Can you post a screen shot of the "Job Title" field as seen in Hornbill? Are you 100% sure that the conf file screen shot above is the conf file that is being used for the import? Are you using the latest version of the import utility 2_0_4? Many Thanks, Dan

Hi Derek,  thanks for uploading your utility log file. I have removed it from the forum as it may contain sensitive information. I'll take a look and see if there's anything that can be gained from it. Thanks, Dan

Hi All,  I can confirm that the root causes to the recent spate of BPM errors seen earlier this week have been addressed in the 2.36.4 and 2.36.5 patches. We of course advise that those of you still on Service Manager version 2.36.3 update to the latest available build in order to avoid encountering these known issues. It is possible to rectify any failed BPM processes effected by these particular issues by using the "Process Restart" capability which retries the last failed operation in a Requests' Workflow. If after updating to the latest build pressing the process restart does not allow the workflow to continue, it is likely a new, unrelated issue and should be reported as such. Dan

Hi All, to establish if you are effected by this issue and whether you need to take the above action in relation to the experimental.bpm.spawnAsync system setting, download and inspect your instances "ESPServerService.log" for the phrase "Security Failure". This will be preceded by the name of the BPM operation that failed due to the absence of a valid session. The full output will typically look like: "2016-11-11 09:21:45Z [DEBUG]:[SYSTEM]:[1444] XMLMC Request Failed: FlowCode Exception ([application name]/entities/Requests/fc_bpm/[Name of BPM Operation]): Security failure" You will most likely be effected if you have autorouting configured to log tickets automatically from email. Dan

Hi Andy,  Martyn is correct. I can confirm that the issue mentioned above in relation to the request details summary and description was addressed in the subsequent 2.36.4 patch. Thanks, Dan

Hi Derek,  if you raise a new test call today using the same service and request catalog item, do you get the same failure? Do you get the failure on all requests regardless of the service/request catalog item? Thanks, Dan

Thanks Derek,  when a template is grey, all it means is that it has been modified from the out-of-the-box state. It does not indicate whether it is being used in any particular BPM Workflow. Thinking further about the error you're encountering, what i'm seeing in your logs is this: XMLMC Request Failed: FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_bpm/notifyEmailCustomer): Input parameter validation error: The element <updateTimeline> was not expected at location '/methodCall/params/updateTimeline' Basically when a particular BPM operation takes place (in this case the sending of an email notification) the list of parameters (node config options) are checked to ensure that the BPM engine has got all the information it needs to complete the operation. What the engine is saying here is, while it was checking each option it's actually found the "updateTimeline" parameter when in fact it was expecting something else at that point, which is usually the parameter immediately above the one it didn't expect i.e. in this case it couldn't find the "Email Template" parameter. This is why I asked you to check the email template value, and that the template actually existed, but that seems to have drawn a blank. When was this particular Business Process Workflow last modified? Thanks, Dan ÂÂ

Hi Derek,  Please can you confirm a couple of things for me, Is the name of the email template specified in your node configuration correct? This is case sensitive and should be specified exactly as it appears in the list of email templates located in System > Email > Templates Does the email template still exist? Thanks, Dan ÂÂ

Hi Derek  please can you confirm if you have clicked the "Restart Process" button (Refresh icon located to the right hand side of the BPM Progress bar). The error (element <subject> expected at....) shown in your screen shot suggests you have and it may be masking the true error message. Please could you refresh the request and let me know if a different error message presents itself? Best Regards, Daniel

To conclude this thread, this particular occurrence of the error that prevented the request from loading, was due to the catalog item against which the request had been raised being deleted. Better error handling has been introduced to deal with the situation where catalog items have been deleted in the upcoming service manager release due early next week. ÂÂ

Hi Paul,  when run, the LDAP import utility works by the following principle. It will evaluate the Hornbill UserId  in relation to the contents of the Active Directory field specified in the conf.json Field Mappings. If the userId does not exist in Hornbill, then a new User account is created in Hornbill. If the UserId already exists, the utility will check to see if there are any values it needs to update including any Hornbill Roles specified in the "Roles" section of the conf file. If there are any new roles, they will be appended to the existing role set. I would suggest amending your conf file to ensure the "Basic User Role" and "Self Service User" role are specified in your conf.json (as per the wiki page: https://wiki.hornbill.com/index.php/LDAP_User_Import) . There is also a setting that you may need to amend to ensure that role changes are applied on Update (this relates to the attribute "userRoleAction"). This will have the effect of associating both the new roles to all users. After doing the above and running the utility, you may want to revert the userRoleAction just to "Create". Hope that helps, Dan

Hi Paul,  I understand. I've just queried this with dev and it seems the operation of the "Associate to All Users" button hasn't evolved to accommodate Basic Users, but they have acknowledged the need and will look to introduce the capability. Are you using the LDAP import utility to populate your basic users? Dan

If you navigate to  Home > System > Organisational Data > Roles in Hornbill Administration, find the "Self Service User" role using the quick filter and click to view the role details. There is a tab towards the right hand side labelled "Assigned Users". Click that tab and I assume you will be presented with an empty (or nearly empty) list of users. There will be a group of smaller button towards the top right of the list, one of which will "Assign all Users". Clicking this will associate the role to all users (Basic and Full application users) but there is no harm in full application users also possessing this role. Thanks, Dan

Hi Paul,  this is most likely due to the roles your basic users posses. If your Basic Users are to access the "My services" section of the portal they will also need the "Self Service User" role. Information can be found on the Hornbill wiki but essentially the concept is this; All Basic Users must have the Basic User Role associated to their User Accounts. In addition to this, they will have a range of other roles depending on what content they will be required to consume in the Hornbill Service Portal. At present, only Service Manager makes content available via the Service portal, but in future other apps may do this also. Information on roles can be found here: https://wiki.hornbill.com/index.php/Roles Hope that helps, Dan

Hi Sean, The approach to continuous deployment updates work in a different way to the more traditional on-premise software upgrades that you may be used to. The below post may help explain our approach to Application Upgrades, let me know if you find that helpful in answering any queries you may have. Dan ÂÂ

Hi Sean,  Updates are applied via the Hornbill App Store which is access via Hornbill Administration > Add More Apps. Once here you will see a Service Manager Icon with an associated "Update" button. You can also reach the App Store by clicking the "Update Available" button that appears on the Service Manager card (see the attached image). Visibility of the App Store is based on the roles you have so potentially you may not have visibility. In that case you will need to speak with your system administrator (If that's someone different to yourself) or log in using the "Admin" user account. Dan

Hi Derek,  thanks for your post. It depends whether this information is captured in a custom progressive capture form or not. The custom forms have the ability for us to set a regular expression on the single or multi-line text input fields. This can help prevent the user from entering irrelevant information. Alternatively, you could ensure all your assets exist in Service Manager and present them with the standard Pro Cap Asset form marked as mandatory. They can then search on Asset tag and easily link the asset in question. Having said that, both my suggestions are not completely infallible, as in the first case the user could learn the format and put in random letters and numbers to satisfy the regex check. In the latter case they could just select the first asset returned in the search. Which arguably is worse because then it's harder to tell whether the information is accurate (at least you know a full stop is rubbish). This then leaves us with the third option which is to play hardball. It's perfectly reasonable for you as an IT Service Desk to expect customers to provide information that will assist in the resolution or their issue or fulfilment of their request. In the event of them not providing the information simply send a stock response saying we are unable to progress your call until we have this information (of course that's the extreme). Perhaps make it Service Desk policy, publicise a "Guide to logging IT calls", present this on your intranet or IT Services web site. Help your customer base understand why this information is important to you and emphasise how it can help you provide a quicker and better service to them. i.e. it's in their interests to do this. I appreciate that this doesn't happen overnight, and customer engagement can be the most challenging aspect of Service Delivery, but customer education can be leveraged in the quest for continual Service Improvement. I hope that helps, Dan ÂÂ