David Hall
-
Posts
658 -
Joined
-
Last visited
-
Days Won
34
Content Type
Profiles
Forums
Enhancement Requests
Posts posted by David Hall
-
-
@Berto2002 We came across this while investigating this morning and this looks like the same kind of issue... if you select the default option '-- filter by status --' in the drop down list does it show the active questionnaires you are expecting to see? If so then if you edit an entry I'm expecting it will also have no status selected. Will be investigating that further now but looks like a similar fix that needs to be undertaken.
-
Details of this issue can be found here
Kind regards,
Dave
-
@Berto2002 Was about to reply to your other post but will refer you to my post here.
-
Hi @HGrigsby
Thanks for posting... I've been investigating and from what we are able to understand it appears that some Impact records may be missing a 'status' value (despite the Admin UI showing as 'Active') as per screenshot. The effect of the missing status means that the Impact name may not be shown on the assessment popup and will not be stored against the request when an Impact is identified (the impact id will still be stored against the request as expected).
The immediate fix is to manually edit the impact status value within the Admin UI and ensure that all of the Impacts you expect to be Active do all have a status of 'Active' set. We will be looking to correct this data from our side as soon we are able to, but should you make the updates manually this will prevent any further issues.If you have any questions just let me know.
Kind regards,
Dave
-
4 hours ago, Blowerl said:
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.
-
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.
- 2
-
@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
- 2
-
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
- 4
-
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
- 1
-
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.
- 2
-
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
-
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 settingservicemanager.email.archiveFolderName
as per the screenshot.. does this match a valid folder in your mailbox?
-
Just FYI in case you need to make the same changes to the individual settings to match a custom request reference.
Kind regards,
Dave
-
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.
- 1
- 1
-
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.regexit should also check these settings when looking for matches. Have these been updated according to the references you now use e.g. GSA?
-
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
-
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.
- 1
-
- 1
-
-
We've been working through (and are continuing to work on) some UI changes to improve accessibility and make the UI more consistent across the available modes which has probably resulted in the hold highlighting not being applied. We'll review the changes, but in the mean time I'd expect that you could use the 'On-Hold' filter link just to give you an immediate list of all requests on hold.
Kind regards,
Dave
-
Have spoken to the team looking after email, regarding not being able to see the previous email content.. can you go into Hornbill Admin -> Platform Configuration -> Core Settings and check if you have the following setting turned on
app.view.email.reply.includeOriginalMessageText
This should enable a button underneath the text area to see the previous content as per the screenshot.
Regarding the apply to email issue this has been tested as working in the next update of Hornbill Core UI which is due to be pushed out later this week.
Kind regards
Dave.- 1
-
Hi @Sam P
Thanks for posting, sorry about the delay in responding. We've investigated the issue and have implemented a fix which will be available in the next update of Project Manager.
Kind regards,
Dave
- 1
-
Hi @Sam P
On 21/03/2024 at 13:30, Sam P said:We've been working on colour improvements in the next Service Manager update and we'll take a look at this to see if we can make some improvement here.
Kind regards,
Dave.
-
On 21/03/2024 at 11:52, Gareth Cantrell said:
We have been notified of some accessibility issues in all 3 modes (Light, Dark & High Contrast) in the new UI request list.
In Light mode, links are rendered as blue text on a light blue background rendering the text almost impossible to read for users with colour blindness.
In Dark mode, links in unread requests are also rendered in the same blue text on a blue background, also rendering these illegible to colour blind users.
In High Contract mode, links un unread requests are rendered in yellow on a light yellow background and the rest of fields are rendered in white - this is illegible to all users.
I have tried playing around with the webapp.view.ITSM.serviceDesk.requests.list.unreadColour application setting, and it has no discernible effect in any mode, except for light mode.
Hi @Gareth Cantrell
As you mentioned the app setting is only really applicable to light mode. We've made numerous changes in all three modes ahead of the next Service Manager update which will be out ahead of the switchover date for the new UI which should address the primary issues you mentioned. We're continuing to make further improvements to the colouring on the request list and if there happen to be any issues following the next update we'll look to address them with highest priority.Kind regards,
Dave.
Impact not showing in timeline
in Service Manager
Posted
@Berto2002 The route will be fixed in the next SM Update.