Caroline

In addition to the above, a user has just had this when completing a release request workflow. The workflow log has this: 1.656896s ERROR Execution Failed: Xmlmc method invocation failed for BPM invocation node '8a21a7f9-dadc-2031-0697-69317467c95b/flowcode-90d43907': <methodCallResult status="fail"> <state> <code>0207</code> <service>apps</service> <operation>updateReqStatus</operation> <error>/apps/com.hornbill.servicemanager/entities/Requests/fc_modules/requests_helper.js(12295): error X1001: Uncaught EspMethodCall::invoke: Operation[apps/com.hornbill.suppliermanager::stopActiveSupplierContractEventAgainstServiceManagerRequest] Your session does not have rights to the &apos;com.hornbill.suppliermanager&apos; application</error> <flowcodeError> <where>Execute</where> <filename>/apps/com.hornbill.servicemanager/entities/Requests/fc_modules/requests_helper.js</filename> <lineNumber>12295</lineNumber> <columnPos>19</columnPos> <message>Uncaught EspMethodCall::invoke: Operation[apps/com.hornbill.suppliermanager::stopActiveSupplierContractEventAgainstServiceManagerRequest] Your session does not have rights to the &apos;com.hornbill.suppliermanager&apos; application</message> <errorCode>1001</errorCode> <stackTrace>systemResolveRequest at /apps/com.hornbill.servicemanager/entities/Requests/fc_modules/requests_helper.js(12295:20)</stackTrace> <stackTrace>updateRequestStatus at /apps/com.hornbill.servicemanager/entities/Requests/fc_modules/requests_bpm_helper.js(4902:35)</stackTrace> <stackTrace>at /apps/com.hornbill.servicemanager/entities/Requests/fc_bpm/updateReqStatus.js(15:41)</stackTrace> </flowcodeError> </state> </methodCallResult> In the workflow the user completes a task which then sets a checkpoint before updating the status to Resolved. If I go into Failed workflows and Restart process it then continues happily. I notice in the more detailed error it mentions suppliermanager which is an app I can see we have installed but we don't currently use and no-one has access.

@Steve Giller Thanks for coming back to me. I found that error in the logs thinking it would be more helpful for troubleshooting. This is what the user saw: As no-one came back to me I managed to find a workaround by creating a Role with the manageApplications privilege and assigned it to the affected users, although this isn't ideal as it could give them access we don't want. It gets the user around the blocker but they now get a different error when resolving tickets. Unfortunately I can't find anything in the logs that provides more detail on this error. It seems whilst the user gets the error, if they come out the ticket and go back in then it is resolved. To resolve a ticket the user goes into the ticket, goes to the Resolution tab, enters a description and selects a category. Error occurs when they click Resolve. Regarding the Super User role, I've had this since day 1, wasn't aware I shouldn't have it. I removed it last week to test something then started getting errors myself when resolving cases, so I put it back on for now until all the issues are resolved.

@Nanette is there any update on this please? It's been over a week and I've still got users having issues.

Thanks @Gerry, I got the metadata URL from my IT, added it to Hornbill, did a refresh as you suggested, and can see it has now picked up the new certificate. Many thanks for your help on this one.

Thanks @Gerry I've read that several times now and think I have figured out what we're missing. I would like to point out that the documentation refers to images that aren't there, which doesn't help, and whilst all the explanation is great for understanding the why, some clear instructions on the how would be helpful - we've had several people here reading them and it wasn't obvious to any of us. My understanding now then, for the auto renew to work we need the following: 1) certificate to be renewed by provider (for us to action with IDP) 2) Meta Data URL to be populated (I believe this is the bit we're currently missing) 3) Auto Update Certificates to be enabled Have I now understood correctly? My original question on frequency still hasn't been answered, the documentation only says 'periodically'.

Thanks @Gerry. I was looking on the old Wiki. So to my simple understanding, if we have Auto Update Certificates enabled at least 10 days before the current cert expires, then 10 days before the current cert expires Hornbill will tell Microsoft to create a new certificate, and will then retrieve the new certificate? What if we've already renewed the certificate, it's just not active yet?

Our SSO certificate is due to expire in 2 weeks and we've renewed it with Microsoft, Auto Update Certificates is set to On, but Hornbill hasn't yet picked up the new certificate. How frequently does Hornbill check for a new certificate?

@Nanette please could I have an update on this, I don't really want to have to give super user access to users just so they can continue their work.

Hi @Nanette just wondering if there is any update on this as this issue is also affecting our users from creating new release requests. Thanks

I have two users who today are unable to close Release Requests and Service Requests (possibly Incidents as well, they just haven't tried yet). They could previously close tickets and have been users for 3 years. I have Super User Role and can close tickets, so this appears to be a permissions issue. I have checked the user's roles and cannot see any obvious ones missing, nor have we made any changes to user access. These are the Roles these users have: I've seen this error in the logs also suggesting a permissions issue: /apps/com.hornbill.servicemanager/flowcode/fc_modules/global_helper.js(316): error X1001: Uncaught EspMethodCall::invoke: Operation[admin::getApplicationList] The following rights [manageApplications] in Group D are needed to invoke the method admin::getApplicationList

Perfect, thanks @Steven Boardman, I have it working now.

Hi We have a workflow that includes an Authorisation node and, if the authorisation is rejected we'd like to make the Reason entered visible to the customer that logged the ticket, either in an email to the customer or via a Notice or update in the UI. At the moment I cannot find a way to do this. Does anyone have any suggestions? Thanks

Thanks both

In the Preview UI when you go into Emails and Apply to Request, you still have the option to edit the email, but when you then apply it ignores anything you've done and pulls in the full email including all previous threads and the disclaimers. This is different behaviour to the non-preview version of the UI. This is confusing that it looks like you can control what gets added to the request, when actually you can't. Also, is there any plan to record the datetime of the email when applying to the request? In the non-preview UI I would add this manually as part of applying the email to a request, but with the PreviewUI I can't, so now I can't track when the email was actually received, only when I applied it to a request (which could be hours later).

Good Morning We've had multiple users report seeing the below error when logging in. If the click Logout, then try again it works. But after closing the browser and starting a new session they again get this error when attempting to login. This is affecting several of our external customers, across several companies, and I have also reproduced. I believe the one commonality is use of Edge as a browser. Has there been any changes in the customer portal cookies recently?

I prefer the old Email view where you could see the date / time the email was received and the first two lines of the email in the Messages list. More space also now appears to have been given to the Folders view which, for those just using the default folders, means a lot of wasted space. Request List looks great though, very much liking this.

Hi We have an external customer who uses Hornbill via customer.hornbill.com, and has very strict access controls (Access-Control-Allow-Origin headers.). They have asked for a list of URLs that will need to be whitelisted to enable the customer to use customer.hornbill.com, including being able to upload documents when logging requests. Our customers just use service manager. I had a quick look at the following link but think this lists more than the customer would access: https://wiki.hornbill.com/index.php?title=Hornbill_Cloud_and_Platform Could someone confirm what needs to be whitelisted for users of customer.hornbill.com? Thanks Caroline

Hi Steve, I have just tried again and still no luck. I can scan other QR codes with the same phone, but not the Hornbill one, it just doesn't find anything in it. For your information, the mobile is a Nokia 5.3. I have therefore got around this by generating my own QR code with the required information, and my phone read that instantly and I'm now setup.

I had the Hornbill mobile app installed and setup, but hadn't used it for a while, and now it's prompting me to setup again. I've followed the on-screen prompts but it won't read the QR code. I've checked with another android mobile and the same thing happens. I'm not sure if the problem is with the QR code generated when you add device, or whether the mobile app is broken, but I suspect it's the former as normal camera on the mobile doesn't read the QR code either.

@Miro thanks for coming back to me, it's not causing me an issue currently as it does appear to be saving even though it errored.

Hi @Miro I have just checked this on our instance. The original issue where I couldn't save the Schedule has been resolved, but the same error is now occurring when saving the Activity having added a Schedule.

Create a new Activity - in Advanced options tick Schedule. Complete the schedule details (in my case it's Run daily, from today, Monday to Friday, expire count 10. Click OK - get message asking if I want to discard changes. It would appear 'OK' has the same action as 'Cancel' and I'm therefore unable to save the Schedule.

We are also experiencing this issue, we'll use a workaround for now.

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.