Jump to content

David Hall

Hornbill Developer
  • Content Count

    507
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by David Hall

  1. Thanks @DFarran that's great. I'll investigate further and see if I can identify the issue. Kind Regards, Dave
  2. @DFarran Thanks for the update, having reviewed the code, it should default to the "highest" visibility level permitted on the request for the user, however if no levels are found it will default to "public". Unfortunately I've not been able to recreate locally to this point, would you be able to post a screenshot/list of the servicemanager roles you have assigned to the colleague that sees this issue, I can then try to match the configuration and investigate further to see if I can pinpoint the issue. Kind Regards, Dave
  3. Hi @lukeb When you place the request on hold, are you using the popup form e.g. If so, the setting highlighted will determine the visibility of the post, it sounds like this may be set to "Owner"? This can be set as needed by the analyst, but you can set the default value via the following application setting Kind Regards, Dave.
  4. @DFarran Apologies missed the notification of your last post. I've just posted this on another thread with a similar discussion ... if the hold action is being performed via a sub-status change, the process should follow that it will use this value if set, if no value is set here then it should revert back to using the previously mentioned app setting. In the upcoming update of Service Manager we've made some back end updates to the operation that posts the timeline update, I've just checked it with this scenario and that is working as expected, so if there is still an i
  5. @Charlie Jones @AndyColeman Just following up on this, if the hold action is being performed via a sub-status change, do you have a visibility leveI set on the individual sub-status as per screenshot? The process should follow that it will use this value if set, if no value is set here then it should revert back to using the previously mentioned app setting. In the upcoming update of Service Manager we've made some back end updates to the operation that posts the timeline update, I've just checked it with this scenario and that is working as expected, so if there is still
  6. Hi @DFarran Just wondering if you are using sub-statuses here? If so then it could be the new visibility level against the sub-statuses that is giving that setting. If you are using sub-statuses, then if you view the sub-status details you should see an option to change the default value e.g. Kind Regards, Dave
  7. @Martyn Houghton So any calendar changes will be immediately observed by any existing timers, so if you add in an exclusion day etc then the timers would respect this and wouldn't elapse during this time. What changing the calendar won't do is alter the target times set on a request. Only when setting or changing the SLA will it recalculate the target times based on the current working time calendar configuration. Cheers, Dave.
  8. Hi @jhiggins It looks like the ORDER BY clause is incorrectly using the entity name 'Requests' where it should be using the table name 'h_itsm_requests. If this is something you have specified manually then if you update it to read h_itsm_requests.h_resolvedby_username it should run. Kind Regards, Dave.
  9. @John C Sorry to hear that, we've moved the category to the right panel to make it more visible on the request without scrolling and provided the action tab to set it so that there is no need to edit the form and then have a popup for selection etc. If the changes have made it in any way harder to use then we're happy to take on board feedback for future improvements. Kind Regards, Dave
  10. Hi @Martyn Houghton So if you were to make changes to the calendar, this would not alter any existing target times etc, however if you were to update the SLA on a request then it would take any changes into account. Does that answer your question? Regards, Dave
  11. Hi @John C In the latest update the category has now been re-positioned to the side bar and there is a new action tab for setting the category as desired. Kind Regards, Dave
  12. What's New: New setting for changing the font of On-hold requests on the request list {CH00157323} Allow user with Manage Mailbox rights to see all mailboxes on a Service form {CH00158249} As a Service Level Manager I want additional rule criteria for SLAs {CH00146261} Create Action Item for setting the category on a request {CH00141466} Add visibility of Assets to User Profile {CH00152000} What's Fixed: Routing rule templates not including user details {PM00158720} Multiple dollar signs ($) are stripped from when the details are pushed to the t
  13. Hi @Adrian Simpkins Yes, changes you make to the SLA configuration will only apply to new requests or if you change the SLA on an existing request, otherwise existing SLA timers will remain intact as per the original config. Kind Regards, Dave.
  14. Hi @davidrb84 We've identified the issue and we'll have a fix in the next service manager update (build > 1781) Kind Regards, Dave.
  15. Hi @davidrb84 Thanks for the post. I can see the same issue here, I'll raise a problem for the dev team to investigate and address. Kind Regards, Dave
  16. Hi @Ann-MarieHolloway I've just double checked this out myself and all looks to be working correctly for me on multiple browsers. If you do find a general issue please post back. Kind Regards, Dave
  17. Hi @Jeremy Just FYI, an overview of the service levels can be found here https://wiki.hornbill.com/index.php/Service_Level_Agreements In answer to your question, the SLTs are service based... so on the relevant services for those teams, you can configure the SLA/SL rules to pick a specific SLA/SL based on a combination of request criteria e.g. the team and priority in your case. If you configure your BPM to start the timers once your team priority have been set, then the rules will process against the criteria and set the SLT accordingly. Here is a screenshot of a quick mock
  18. Hi @Martyn Houghton It will be a Service Manager update. Cheers, Dave.
  19. Hi @Jeremy We already have an update with the fix in beta testing which we are about to push live so it should be available for you this afternoon. Regards, Dave.
  20. @Jeremy @Martyn Houghton Thanks for posting. We're aware and are looking into this and will look to alter it to open the email directly. Kind Regards, Dave.
  21. Hi @Shamaila.Yousaf As per the screenshot, if you open the service details -> SLAs tab and find the service level that is used on your request you should be able to see which Working Time Calendar is used with it. You will then need to log into the admin portal and the "Working Time Calendar" view where you should be able to find the calendar and the hours it is set to run in. Just a note of caution this *could* be shared by many services etc so be sure to check before changing it, else you may need to create a new 8:30 - 5 calendar and use that against your service level. K
  22. @stuartmclennan If this is exporting from the requests list, then I can confirm that there was an issue recently where some fields were not being correctly exported, these included description and resolution text. The issue is fixed in the next update (build > 1739) which is due out imminently, so after taking that update you should have the fields available again. Regards, Dave
  23. Hi @aykut.boyraz Yes, in the service level configuration you can add escalation actions to run a set number of minutes/hours/days before a target time. In these escalation actions you can choose to send an email to the owner or to a specific email address which should cater for what you need. Further details can be found here https://wiki.hornbill.com/index.php/Service_Level_Agreements and https://wiki.hornbill.com/index.php/Service_Levels Kind Regards, Dave
  24. Hi @nasimg Thanks for the post, just tried this out and yes there is an issue with the rights checking just on the reopen action on Known Errors. I'll raise a problem so that we can get this addressed. Kind Regards, Dave.
  25. Hi @Lauren There was an update to Hornbill collaboration last night as detailed here with an improved activity stream.. There should also be additional detail in your Hornbill System notifications. Kind Regards, Dave.
×
×
  • Create New...