Deen

@chriscorcoran the following defect was confirmed today which will directly impact this. Although I do not yet have a release date for the fix: Sub-status pop-up When the logged-on person is a Request's owner, "Owner" is selected by default in the visibility selector. When the logged-on person is not the Request's owner but is a member of the assigned team, "Team" is selected by default in the visibility selector. In conclusion, the default item in the visibility selector is based on your visibility to the Request (returned by Requests::getVisibilityLevel) and the setting "guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.hold" is not respected.The expected behavior is:If the sub-status has a visibility level defined (in Service > Config > Request Sub-statuses > Edit sub-status > Timeline Visibility field), use that. Else, use the visibility defined in guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.hold.

@chriscorcoran the owner of the request has the option to set the visibility to 'Owner'. As a result they would then be the only one that could see that particular timeline update. Also if no visibility default is set against the service sub status it may default to Owner. Check if the Timeline Visibility option is blank.

When viewing the email the Apply To Request box allows you to type in manually a valid reference number. You can then select this request to add the email to, it shouldn't need to be a request from the originating party.

The following may help: https://wiki.hornbill.com/index.php/Service_Manager_Notification_Settings Particluarly this part: Note: Email notifications for users on customer/service portal updates and approval emails are sent using a direct method, they do not use any mailbox. The originating email address for these emails is guest.app.requests.notification.emailPrefix@guest.app.requests.notification.emailDomain meaning the resulting email address must be correct and valid. All other notifications are sent via the mailbox using the one configured on guest.app.requests.notification.emailMailbox.

Under the User Options tab for the import setting it to create only and not update is the only way round this that I can see, as the User Type field will only accept a value of 'basic' or 'user'.

Although sending that initial email is a good measure of a first response, using the timeline update or conversations may not be the best method as they could easily be internal only updates and not an actual response to the customer.

@Vikki Cameron @Adrian Simpkins @lokent we have pushed out a new build that should correct this problem. Refresh your browsers and give it a try. Please let me know if the issue persists.

We are aware of the issue and are currently looking into this. I'll post back shortly when I have further info.

@LifeOfJonny would probably be best if you raise this as a request with the Support team for further investigation.

@DFarran sounds like a possible defect, i'll discuss this internally and get back to you.

@Tina.Lapere if you want to try again the new build (1967) is available now.

I'll lock this post as this is discussed in more detail in the post above. The following root cause analysis provides further detail on the nature of the issue: On Wednesday, 17th June, at 09:32, we were alerted to an issue that prevented customers from viewing or updating requests in Service Manager. The root cause has been identified and relates to the Service Manager application cache not being reloaded correctly. Specifically, the application stored queries were not being reloaded after updating Service Manager to the latest build.A workaround of manually reloading the application cache was communicated to customers a few minutes after the first report was made, followed shortly thereafter by appropriate updates to release notes communicated on the forum and within the Administration Tool. Furthermore, a permanent fix has also now been implemented and was deployed in a recent build of the Hornbill Platform over the weekend.We apologise for any inconvenience this caused.

The following root cause analysis provides further detail on the nature of the issue: On Wednesday, 17th June, at 09:32, we were alerted to an issue that prevented customers from viewing or updating requests in Service Manager. The root cause has been identified and relates to the Service Manager application cache not being reloaded correctly. Specifically, the application stored queries were not being reloaded after updating Service Manager to the latest build.A workaround of manually reloading the application cache was communicated to customers a few minutes after the first report was made, followed shortly thereafter by appropriate updates to release notes communicated on the forum and within the Administration Tool. Furthermore, a permanent fix has also now been implemented and was deployed in a recent build of the Hornbill Platform over the weekend.We apologise for any inconvenience this caused.

@Mette Petersen Having had a look through the existing roles I cant see an easier way of doing this. The only Calendar specific role that I can see is the Change Calendar Viewer role.

@7oaks that is strange, when expanding the details section normally both the Summary and the Details would be shown. They should remain that way if the section is pinned. Post a screenshot of what you're seeing if you need further assistance.

@Adrian Simpkins It sounds like the problem may be browser specific, if she uses an alternative browser such as Chrome does the problem still occur?

@7oaks Using the pin icon on the Details section should leave it expanded permanently for all requests which should then make it front and centre when viewing a request. If you are referring to the list itself, hovering over the reference should display the description.

@Ann-MarieHolloway good to hear, we'll be in touch with the root cause shortly.

@Ann-MarieHolloway you instance should be updated also now..

@Alberto M should be done now...

The fixes are being applied now. @Ann-MarieHolloway i'll let you know when your instance is updated.

@Alberto M yes, the fix is being separately applied to each instance.

@Shamaila you should be able to do it in bulk from the front end if required. Check the box next to each request to select it and then select the Actions button on the toolbar. There should be an option to close the selected requests.

@AndyGilly No problem, for now though the join on Service ID is the only option I can see. When there is progress on the enhancement i'll let you know.

@AndyGilly this hasn't been formally accepted yet but I have asked if it can be. If you need this quickly the best route might be to look into crafting a report and using table joins to link the domain data to the requests.