David Hall

@Lauren @samwoo With regards to the above references you have mentioned, I was just looking to understand the request lifecycle and ask if: 1. Was the Service Level updated (either manually or by auto SLM rule updates) prior to the hold/take off-hold action? 2. Had the request been placed on hold until a specific time or just indefinitely using sub-statuses 3. Is it possible at all that the related BPM process calls the Mark Response/Fix node around this point e.g. based on a status change? Whilst I can see exactly where it is failing I'm currently unable to replicate locally and haven't as yet been able to understand under what scenario this situation arises so any information you can give would be appreciated while I continue to investigate. Kind Regards, Dave.

Thanks @samwoo I'll take a look, I can see the relevant error in the logs, just working on being able to replicate on demand. Regards, Dave.

Thanks @Lauren I'll see if I can find the errors in the logs and review. Regards, Dave.

Hi @Lauren We'll need to investigate this a bit further, do you know what date/time this error occurred and/or what the request reference may have been so that I can have a look in the logs? Kind Regards, Dave.

Hi @Keith As always this is somewhat complicated to explain so if the following is not clear then don't hesitate to ask further questions... Until now, when changing a service level on a request, the new target times have been recalculated as: * Original Target Start Time + new SL duration (applied according to the associated working time calendar) However, we have never taken into account any working time spent on hold, so you could end up in the following scenario: SL1 Resolution Duration = 1 Hour SL2 Resolution Duration = 4 Hours SL1 Request Raised and Target Started: 9am - Target is 10am SL1 Request Placed on Hold: 9:10am Until 2pm SL1 Request Off-hold @ 2pm: New target is 2:50pm At this point (2:50pm) the SL is deemed incorrect and should be downgraded to SL2 SL2 is Applied to Request: New target is 1pm (9am + 4 Hours Duration) [Target is already missed despite being lengthened] The effect of this new setting being enabled is to handle situations as above, so with the setting on we will now see the calculation as: SL2 is Applied to Request: New target is 5:50pm (9am + 4 Hours 50 mins (on hold) + 4 Hours Duration) If you want to revert back to the previous method of operation then changing the setting will revert you back to the original calculation method. Kind Regards, Dave.

Hi @Ann-MarieJones The response in this previous post may assist with clarification, if not then please post back. Kind Regards, Dave

Hi @Michael Leonard Normally you will see this message if you do not have access to the mailbox in which the email sits, are you able to find and view the email via the main email view? If not then you most likely need to be granted rights to view that mailbox. Kind Regards, Dave.

Hi @davidrb84 Apologies for any inconvenience, I've asked the relevant team to have a look at your instance to see if there are any issues they can see. Kind Regards, Dave.

Hi @HHH I've investigated this further and to fix this we require a fix to both the activity stream component and to the service manager app. The component change has been made and I am just waiting for this to be released to me so that I can confirm that the fixes to the application have worked. I'll raise a problem record for this internally to track this and we'll get the fix in as soon as possible. Kind Regards, Dave.

Just to follow up on @Victor's previous post, this was identified previously and was fixed in build 1408 of Service Manager, from that build onwards the catalog name should be populated when raising requests via the routing rules. Regards Dave.

Hi @Keith h_fixtime is the value you most likely want, this is the time taken to fix in seconds. h_fixsecs is the fix target duration represented in seconds. Hope that helps, Regards, Dave

Hi @Ann-MarieJones Following on from the above post by @Victor you may be seeing them if they have been configured by your colleagues to be globally shared statuses rather than just being restricted to one request type or service. If you need any details on the configuration either globally or by service the details can be found in these links. https://wiki.hornbill.com/index.php/Global_Request_Sub-statuses https://wiki.hornbill.com/index.php/Request_Sub-statuses Regards, Dave.

Hi @Jeremy Sorry for the inconvenience, seems it was back before I was able to post a response. I've just asked to see if there was any specific issue we can feed back. Kind Regards, Dave

Hi @Cizzling I've been through the code and I've managed to track down the issue. I've raised a problem for it and we'll get this corrected as soon as possible. Unfortunately it won't make it into the imminent update of Service Manager but it will be in for the next full update after that which will follow roughly 2-3 weeks after. Regards, Dave

Hi @Lauren Sorry I've been trying to confirm where that would be configured and then I realised this is probably your service or customer portal. For each of those there are an additional set of translation strings I'd forgotten about. So again in the service manager translations view in the admin tool if you search for: Service Portal: guest.com.hornbill.servicemanager.portals.servicePortal.pcapture.site or Customer Portal: guest.com.hornbill.servicemanager.portals.portal.pcapture.site Then hopefully it will be one of these that currently contains that text. Let me know how you get on, Regards, Dave

@Lauren These translations are under Service Manager, so you need to navigate to Home -> Service Manager -> Translations and then you should see them there when you search. Regards, Dave.

Thanks @Cizzling I'll have another look to see what visibility controls there are around the 'Site' item and get back to you. Regards, Dave

Hi @Lauren The progressive capture translation strings normally all begin as user.view.pcapture and for the site forms you should be able to type in user.view.pcapture.site into the translation strings search in the admin portal which should list all of the translatable text used in those forms as per the screenshot. If you can't find what you need there then let me know any specific text and I can have a further look. Kind Regards, Dave

Hi @Cizzling Thanks for the post. We noticed your first issue with the "Site" selection filtering not working in the full subscribers list during our last testing cycle and therefore we have a fix already in place which will be available in our next update of service manager (build > 1401). This build is already in beta testing internally so will be available very soon. As for the second issue of the 'Site' option not being available when managing the subscribers in the service, I do not see this myself on my instance and it should be a hardcoded item that is always available. Perhaps you could post up a screenshot of the list of options you are seeing so I can review further? Kind Regards, Dave.

Hi @Lauren In Hornbill we do store that value if you are using the Service Level Targets but it is now recorded against the target (Response/Resolution) etc rather than in the request record itself. Depending on how you want to use it, the value is stored in the RequestSLMTargets entity (h_itsm_request_slm_targets table) in a field named h_target_completed_duration . So for the fix time you would need to look at the record in that entity where h_id = <RequestId>-Resolution e.g. h_id='IN00001234-Resolution' Hope that helps, would be good to understand how you want to use it e.g. on the screen/reporting etc in case there is a better way to provide this information going forward. Kind Regards, Dave.

Hi @Izu The "Admin Role" is required to manage/update applications etc from within the admin tool, so only those users that act as administrators of the instance should have the "Admin Role" allocated and only they will be able as appropriate to update applications etc. Hope that helps, Kind Regards, Dave.

Hi @HHH Of course no problem, I've already mentioned this post to our product managers and asked one of them to review. Cheers, Dave

Hi @HHH All of the "guest.servicemanager.portal.home.*" settings were added to control the layout on the home page of the portal e.g. icon sizes and which information should be shown in order that customers can tailor the view based on the number of services that are normally presented to their visitors. There are currently no specific settings around the description visibility on the service details page. Kind Regards, Dave

Hi @Jeremy Thanks for the post. We've just tried this out and it appears that it is the double quotes in the task name around "AppsAnywhere" which are causing the link formatting to break on the timeline post. We'll raise a problem to address this issue, however in the meantime you could alter the double quotes to single quotes in the task name which should correct the timeline formatting. Kind Regards, Dave.

Hi @BobbyB Thanks for the post. No, with sub-statuses you are not able to unset the status, only select an alternative sub-status. Kind Regards, Dave.