David Hall

Hi @Blowerl You are most likely using the default value of 'Opaque' in this service manager application setting webapp.view.ITSM.serviceDesk.requests.list.onHoldFontStyle . If you change this to 'None' as per attached image it will make the content clearer. Kind regards, Dave.

@Andy McKey @mhhf Thanks for the post, following the rollout of the new UI we have been working through some of these highlighting issues. In the next Service Manager update scheduled to be released next week we have corrected issues with the highlighting of on-hold calls in light mode; dark mode did not use suitable highlights but in the next update we will have row highlighting available with colours based upon the light mode selections. Hopefully this provide the highlighting you need but we will continue to make improvements on it as needed based on feedback. Kind regards, Dave.

@Gavin James - SDDC @StephC @Emily Patrick Sorry for the delayed reply but I have not been in the office the past week. Just to clarify the current situation, the row highlighting is actually still present however with the introduction of the light blue background in the new UI it is no longer clear to see, hence we will alter the colour to be more visible in the next update of Service Manager which will also include a fix for the font formatting which is incorrectly not being applied. Just to re-iterate the filtering options to the top left of the request list provide for easy filtering of on-hold requests so keen to understand if this is not a viable alternative in the time until we are able to push the next SM update which we anticipate being early next week. Kind regards, Dave

Hi All, Just to provide an update.. A darker colour highlight we be made available in the next update for on-hold calls so that the distinction will be clearer. We have also identified why the font formatting is no longer being applied and this will also be corrected in the next update. Kind regards, Dave

@mhhf There is still a highlight set for the on-hold status however its almost unnoticable against the new background... we haven't changed that as yet but we'll look to get a more visible highlight put back in next week. All of the other row highlighting should still be working as before. Perhaps the contrast or brightness on a specific screen is enabling you to see it more obviously? @Emily Patrick The difference with the first row in your example could be that it has it is currently 'unread' or 'updated by customer' where another style overrides the on-hold. We're looking to address these concerns in the next update. Kind regards, Dave

@Llyr @Gareth Cantrell Good to hear it's now working as expected. Despite it looking identical the apply email function has been completely rewritten for the new UI and I believe that in the previous version we were only returning an error when the actual applying of the email failed... but if the move to archive failed it was silent rather than reporting the error as it correctly does now. Kind regards, Dave.

@Gareth Cantrell Just checking is this happening every single time you use apply to email or on occasions? Also are the emails in these cases correctly moving to the archive folder you expect? If that all looks correct then it might be better to log this with support so that we can take a look at your instance and diagnose the exact issue as I'm not currently able to replicate in our environment. Kind regards, Dave

Hi @Gareth Cantrell @Llyr If the email is being applied correctly then I'm wondering if there is an issue when its trying to move the email to your chosen archive folder. If you check the app setting servicemanager.email.archiveFolderName as per the screenshot.. does this match a valid folder in your mailbox?

@Andrew Tasker Just FYI in case you need to make the same changes to the individual settings to match a custom request reference. Kind regards, Dave

@Euan Coleman Happy to hear that's corrected things. Apologies for the inconvenience. The reasoning for making the change was that until now on every keypress in the search field a new search was fired, this could mean 8 or more searches being fired as you type a reference and it was a big hit on performance, this change was to identify when a valid reference format had been entered and only then perform a single search. In order to cater for the possibility of different request formats we had to use the above settings which we incorrectly assumed would have been updated as part of selecting a new request reference format but unfortunately that wasn't the case here so apologies, in retrospect we should have communicated that in the release notes and will look to do so with any such changes in the future. Kind regards, Dave.

@Euan Coleman Having checked again in more detail.. we have individual settings for each of the request types (which are not readonly) which all appear under this setting search as advanced settings.. com.hornbill.servicemanager.regex it should also check these settings when looking for matches. Have these been updated according to the references you now use e.g. GSA?

@Euan Coleman Apologies.. this is most likely the issue and I wasn't aware it was a readonly setting... let me work out if we can make changes or else we'll remove the change. Will update you asap Dave

@Euan Coleman Just something to check.. there was a performance tweak which now checks for a valid request reference format before making a search... I notice you have a 3 letter request prefix so if you check the setting in the screenshot.. has this been updated from 2 to 3 in the curly braces to match the new format ? If not then might be worth changing it to 3 and then retrying. Kind regards, Dave.

@Emily Patrick Thanks, we'll take a look at that at the same time Dave.

@Julie K Posted up here