Caroline

Many thanks Steve and Armando for looking into this so quickly.

As mentioned in my post, they work for about a week then stop working, so you won't be able to reproduce straight away. Example. I created a new View last week, filter on Organisation x (ID 4) and Status is Open, New, OnHold, Resolved. It worked fine last week, but when I came in this morning and selected the view I got a list of requests for Organisation y (ID 3) (the View criteria still has Organisation x (ID 4) selected). The only way I can 'fix' this is to either delete the view and create again, or to remove the Organisation from the filter, then select the Organisation again. However it's getting very frustrating to have to do this on a weekly basis. I've tried both these 'solutions' and neither resolve the issue permanently, I still find the View filtering on the wrong Organisation after about a week.

Background - we have a number of customers set up as Organisations (Contact/Organisation). We then have a number of Views setup by Organisation so we can filter the open requests by Organisation. Issue - the Views for some of my Organisations keep stopping working. I'll set them up from new (with filters Organisation is x and Status is Open, New, OnHold, Resolved) and they work fine for a while, then maybe a week later I'll select the View and get a list for a different Organisation. I then have to edit the View or create another new one to get it working again. It's always the same Organisations affected, and looking at it today (as they weren't working when I logged on this morning), it looks like Organisation 5 is showing results for Organisation 4, Org 4 is showing Org 3, and Org 3 is showing Org 2. Org 1 is still showing correctly. Has anyone else seen this and is there a solution? It's very frustrating to keep having to redo the Views on a weekly basis.

We're also affected by this, down for a second time...

Thanks Victor

Hiya, I've been asked by my security peeps to check if Hornbill uses Spring Framework and therefore could be exposed to the spring4shell vulnerability reported by Spring this week. https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement Thanks

@Steve Giller Thanks for the update. I'm asking about Incidents that have been logged over the last couple of days that have no SLA

Thanks @Deen Is there anything that can be done about the Incidents that are missing their SLA?

Hi, we're another customer affected by SLAs missing on new Incidents, issue started yesterday. This will impact our customer reporting. What's the ETA on a fix?

Thanks Steve, I don't believe it's the latter as only one of my colleagues marks them as read, and he's not in this week, so would only be me updating them. I've just had it happen again: updated a request in Service Manager, then 5 minutes with no browser activity, then back to Hornbill, went to Email, mark all as read and got the error, so shouldn't be 'stale' as I've only just changed view to Email.

It doesn't happen every time, but I usually see it at least one a day. Based on this latest occurrence, I wonder if it's possibly happening after I've been inactive in the window for a while, then try to mark them as read. I'll try to be more aware of my actions immediately prior to it happening. Screenshot of the error: And a screenshot hopefully showing that number of unread emails is still showing 12, but there are none unread (data security, I can't show more than this).

We regularly get the above error when marking all emails as read. The window then has to be manually refreshed as it still shows x unread (the individual emails are read, but the count in the left hand panel remains). It really is rather annoying, is there anything we can do to fix it?

Hi @Victor Currently we are taking the PCF answer and putting it directly into the Auto Authorisation details as we didn't have a need to store it elsewhere. I will have a look at mapping it. Thank you for the suggestion.

Thanks @Victor you are correct, they don't match. I will make the change and test if that fixes the problem. Thank you

Request Category is part of the 'catalog' PGC, so the same form should be used regardless of who is logging the call. However, if the call is logged via the customer portal then it just stores 'Enhancement Request', i.e. the second level but if the call is logged by a support analyst via the live site, then it stores as 'Service Request: Enhancement Request', i.e. levels 1 and 2. Is there anyway to make this consistent? This is causing an issue with our reporting (see excerpt below). Requests->Category Name Service Request:Technical Request Enhancement Request General Question Service Request:Enhancement Request General Question Enhancement Request Service Request:Enhancement Request Enhancement Request

Hi @Yodit Thanks for that solution, it works well within Hornbill, and the authorisation task is now correct, but the authorisation email still has zulu time which is still causing confusion. How do we get the correct date in the email?

Thanks @Martyn Houghton, it finally showed after 45 minutes. The other search options don't help when I'm trying to apply an email to a request which was where I got stuck.

A customer logged a new request at 14:10, then followed it up with an email. I'm attempting to apply the email to the request, but it's not finding the Request, despite me checking the reference is correct. I also cannot find the Request by reference if I use the search bar at the very top of Hornbill. It's now 14:33 and I still can't find the Request. I've tried in both Chrome and Edge.

Hi, I have a date / time captured in Progress Capture Questions which I then use to populate Details and Tasks via the Business Process. Unfortunately this is then coming through as GMT not BST, which is causing confusion for the authoriser. It shows correctly in Questions but not in Tasks or when I append to Details. How can I get it to use the current time zone and not zulu? Question: Task: Details:

Following on from Hiten's update yesterday, we have now removed all languages but English (British). We would however like to understand when this changed, as I don't recall seeing any announcements about this. To confirm, we had not made any changes to the customer portal prior to this issue, and it was working fine, so we just want to understand what changes Hornbill made and how we would have been made aware of these. Thanks

We have some users whose email address is different to their Login Id. The system appears to be using the Email for logging in, not Login Id, which is causing problems where multiple users have the same email address (e.g. shared team mailbox). These are Guest accounts for our external customers. What is Login Id used for if it's not logging in, and why is the authentication using Email not Login Id?

Ignore me, just found the setting. Apologies. webapp.view.ITSM.serviceDesk.requests.list.enableNoTeamAllUsers

When we get new calls we don't auto-assign Team, so we get the 'x No Team Assigned' link in the top right of the Request List. Some of our service analysts aren't seeing this link when others are. Can anyone advise what setting controls visibility of this?

Hi @James Ainsworth Yes this is still occuring. When trying to view Saved queries I get: And when updating or saving a new query I get: And at the time attempted to save there is the following in the EspFileService log 2 15 Jul 2021 08:13:42 error process 6124 Folder does not exist.

Thanks all for the replies, I've sent Steve G the details for Hornbill removal. Are there any plans to allow users or superusers to do this? As mentioned, it is for data security reasons that we are looking to remove it, therefore we would like to be able to do this ourselves.