David Hall

Thanks @DFarran that's great. I'll investigate further and see if I can identify the issue. Kind Regards, Dave

@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

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.

@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 issue it should be corrected in the next update > build 1805. Kind Regards, Dave

@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 an issue it should be corrected in the next update > build 1805. Kind Regards, Dave.

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

@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.

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.

@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

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

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

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 timeline of a Request {PM00158408} Wiki markup date in the Summary field is not formatted in the Request page title and Requests List {PM00158134} Collaboration only users should be able to see the details of a Change they're authorising in the portal regardless of the overall app-setting {PM00158362} When viewing a Request that belongs to your staff in the My Services portal, the timeline and post box are sometimes not available {PM00158433} Cannot send notifications if a User ID contains a single quote {PM00158790} When sending an email through the Business Process, the connections filter is ignored {PM00158798} Known Errors cannot be reopened due to checking of a missing app right {PM00158372} After posting to the timeline of a Request, another request action's visibility cannot be changed to a higher value than the original posts visibility {PM00157146} Request data including summary is not shown in Request list on Service page or mobile requests view {PM00158923} When a View is deleted, the entries in shared Views are not removed automatically {PM00158946} A chart showing the number of requests grouped by Rating fails to display the rating value {PM00158951}

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.

Hi @davidrb84 We've identified the issue and we'll have a fix in the next service manager update (build > 1781) Kind Regards, Dave.

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