Steven Cotterell

Morning folks. Any scheduled daily reports are showing as 'Pending' for us too. Any update or ETA would be appreciated. Thanks.

+1 please - Filter would be good, but could we also have the option to store in folders too to help group types of views?

+1 for us please - we have just come across the requirement to add more descriptive info in the panel on the right-hand side for this Progressive Capture node. We wanted to add something like the following as a guidance for the 'Summary' & 'Description' field.

Hey @yelyah.nodrog, Just wondering how you've got on with your integration with Remedy? We have stated to one of our customers that this is possible (they raise a ticket in their Remedy solution which then raises a ticket in our Hornbill Instance) and have just started looking at the Community forum for any 'gotchas', 'insights/inspiration'. Steve.

Thanks @James Ainsworth, I totally appreciate your concerns. How do I go about engaging with Support please so that we can remove the data from these fields in the DB. I'm happy to do it, but don't want to go against advice from you guys. I want to do it with the 'overseeing' of Hornbill Support.

@Martyn Houghton, cancellation reasons can be self defined... check here... Cheers Steve.

@James Ainsworth, it appears the only rows in this table for 'Change Requests' are the ones where I have clicked on "Revert to Default" or modified the 'Request Category'. Almost every service that we have has the 'Change Request' request type enabled, so the fact that the query only shows 6 rows are returned marries up with the research I've done on the services returned in the query. For the row returned that shows the 'Request Category' changed, this is no longer needed so I will be removing this setting in the Service (h_service_id = 169). I think we need to either just remove the data in the field called 'h_service_request_form' for the 5 rows that refer to 5 Services where I'm having the issue with the form not displaying or we just remove these rows from the table all together as they hold no real purpose. Thoughts? Cheers.

@Steve Giller - Ah, that would be great if we'd set-up our users based off our Azure / O365 accounts. However, we didn't. We manually created them all during our Switch-on. There must be a way that we can export settings and re-import with amendments....??

Thanks for replying @Steve Giller, these are existing users. Can we use the Data Import Tool for existing users? I'm thinking we would need to do an export first to get a list of users with IDs and settings in some sort of CSV file, then re-import the users with the modified settings. Am I on the right lines?

Hi, We would like to be able to perform a mass change to the 'date/time' & 'date' formats in our users profiles without having to go into the profile settings for each user and select the required setting/style. Can anyone suggest a way forward please? Thanks

+1 for us please

+1 for us please also - we like Martyn's suggestion. Any progress on this please since someone last asked back in February?

Thanks @James Ainsworth. There are no other settings/modifications stored in these rows for these services, so is this one of those 'rare' times where Hornbill would allow us to remove these rows from the table?

I have just used the 'RESTORE DEFAULT' option on another service id that was working. Now I have an entry in this table for it and low-and-behold the new default form no longer displays. @James Ainsworth, doing this seems to not revert the form correctly.

I've found this using 'Database Direct'. The 'h_service_id' of the above mentioned service is actually '245'. The query seems to show some customisation, however I have definitely used the 'RESTORE DEFAULT' option on the Details form. I have checked creating a Change request for h_service_id '351' also and I'm getting the same behaviour, the new default form is not being selected, despite again ensuring that the form has been restored to default. When I pick a service not mentioned here, the form is correct. Can someone verify why the DB is not updating please (assuming I'm looking at the correct table). Thanks, Steve.

Hi, I have noticed that on at least one of our services for the 'Change' request type, that, despite using the 'Restore to default' option on the 'Details' form, it is not using the 'default' request form for a Change Request (that I configured using the recommendation below from @James Ainsworth). I need to be confident that every Change created now uses this new default form, but without creating a 'test' Change for every one of our 100+ services, how am I going to know this. There must be something at the DB level that identfies whether the Details form for a Change request is using a custom one or the default. Can anyone shed some light as to where to check this please? Thanks, Steve.

Just as I was typing this, we have had another Incident trigger as Breached by the Escalation Events, IN00000407. The SLA has not actually breached, but cards are being put on the Board & emails are being sent out indicating this as a breach. All 4 escalation events have fired at the same time despite them being configured at different intervals to fire, so this is no longer now an isolated issue.

Hi, is there anyone out there that has the time & knowledge of the log to help me get to the bottom of this issue please? Thanks, Steve.

I have an extract from the EspServerService.log which I can zip, encrypt & send to Support if that helps (don't want to post here though).

Board Timeline shows the card for this ticket being added to the board and then being moved down the lanes at the same time.

Hi @Deen, I've checked the Escalation events and also had someone else verify these. I've seen some Exceptions thrown in the 'EspServerService.log' at the time when the first Escalation fired (which was 20 minutes into the an 8 hr Resolution SLA), which was configured as 4hrs before target. These figures don't add up. I have saved the EspServerService.log. Also, forgot to mention, no, the SLA has not been amended on this request.

Hi, We have noted an Incident Request that has reported as Resolution SLA Breached by an Escalation Event, despite the Resolution SLA not actually breaching. Is there anyone in Hornbill Support that can look into this for us please. I have checked as much as I know about (and I set all this up) so at a loss why the Escalation Events have triggered. Not seeing this anomaly on other Incident tickets. Happy to share the details 'offline' to someone. Thanks, Steve.

Actually, good point - I'd not seen anything about this either. Thanks @Victor

No worries - glad to help.

Click the 'Applications' tile and all will be revealed. Cheers, Steve