David Hall

Hi @Adrian Simpkins I've been unable to replicate this issue so far and from a review of the code there are checks to try to ensure that only when the owner has changed does it try to update the member on a request board card. From the screenshot however I notice that there are multiple errors shown from trying to attempt to assign the request to the existing team/analyst. In my local tests we prevent the assign button being active in the browser if the selected team or owner are not different and the error is only shown when we fall back to server checks. I guess my thought is that the board error is a knock on effect from an invalid attempt to assign the request to the existing team/owner.. are you able to confirm why/how the analyst in this example is able tot try to assign to the existing team/owner? I'm just wondering if there is a specific BPM process or action within a process etc that could be causing an issue? Kind regards, Dave

Hi @MichelleReaney Thanks for posting. I've just investigated and can confirm that there is indeed a defect here. I've raised a problem record and we'll look to get this corrected in the next update of service manager. Kind Regards, Dave.

Hi @Malcolm Within the admin view for service manager you can search application settings for 'hideUnansweredQuestions' which should give you the settings to achieve this. Kind Regards, Dave

Hi @Jim Have a look at this related post and hopefully that will provide the answers you need.. if not then let me know. Kind Regards, Dave.

Hi @Martyn Houghton Apologies for taking some time to reply on this thread. Having reviewed the code you're correct that the 'fixed' outcome for the portal is currently hardcoded to close the request and does not take into account your situation where you have enabled the pause timer functionality. In my view this should check for such a scenario and perform the relevant timer closure etc as per the user client so I will raise a problem record for this so that a full fix can be investigated. Kind Regards, Dave

Hi @chriscorcoran Is this happening via an automated update of SLA when request details have changed or via a manual change of SLA on the request? If its automated then I'd start by checking if you have a Service Level rule that matches your request details for the Lum P1/P2 SLA... if not then it would reset the targets and you would see the result in the screenshot where you have an SLA (via a matching rule) but no Service Level due to no matching rule. Kind Regards, Dave

Hi @Adrian Simpkins I've made some small adjustments to try to prevent this overlapping... this will be in the next SM update. Kind Regards, Dave.

Hi @Mark (ESC) I've rolled out a fix so you should now be able to add/edit the targets. Let me know how you get on. Kind Regards, Dave

@Mark (ESC) As we've just had an update go out today it will probably be a while... so instead I'll look to prepare a hotfix which I'll apply tomorrow morning. Will update you here when the fix has been applied so that you can verify the issue has been corrected. Kind regards, Dave

@Richard Edwards Thanks for posting.. I can see a similar thing here on my instance so have passed this onto the relevant team to investigate. Kind regards, Dave

Hi @Mark (ESC) The issue has been identified and we now have a fix that we will look to push out in the next SM update. Kind Regards, Dave.

Hi @Mark (ESC) Thanks for posting... there does appear to be an issue here with the button not showing. Will investigate further and post back when I have more information. Kind regards, Dave

Hi @Claire B Thanks for the post. The column you would be looking for is in the requests table h_itsm_requests the column name is h_createdby which is documented within this reference https://wiki.hornbill.com/index.php?title=Table_Info:_Main_Request_Table Hope that helps. Kind regards, Dave

Hi @Dave Longley If I understand correctly and you just want to not set the SLA for a single catalog item then you should be able to add an extra rule in the above screenshot to exclude it e.g. Kind regards, Dave.

Hi @billster Thanks for the post. I've investigated and have found the cause of the issue. We've put a fix in place and this will be part of the next Service Manager update. Kind Regards, Dave

Hi @JakeCarter From the employee portal the export is fixed to export just the primary set of data being shown in the view, analysts can export a much wider variety of content from the requests view if desired. If there is a particular use case for extending the export content then please post back and it may be considered as a future change. Kind Regards, Dave.

Hi @Gavin James - SDDC In the Application Settings for Service Manager... if you search for app.request.questions.hideUnansweredQuestions and turn that setting on it should give you what you're looking for. Kind Regards, Dave

Hi @Adrian Simpkins Just had a look.. I think the issue (based on your screenshot) is that you do not have a value in the "Alternative Customer Label" field which has been made a required field in the updated admin view. If you copy the contents of the name field into that field you should be able to save as needed. Let me know if that helps. Kind regards, Dave

Hi @Mark (ESC) Thanks for posting... this has been previously reported and we have a fix coming in the next update of Service Manager. Kind Regards, Dave.

Hi.. thanks for posting up.. this had previously been reported so we already have a fix ready to go and it will be in the next Service Manager update. Kind regards, Dave.

Hi @Martyn Houghton Sorry I wonder if this is yet more UI confusion :/ Once you've clicked the Add button... if you click the "View Translations" button under the label.. it should return you back to the list of translations (either that or reopen the popup form) I've come across several of these usability type issues myself in this form.. if you can confirm if it is functionally working then we can look to improve the UI usability as soon as time allows. Kind regards, Dave.

Ah great stuff. Yeah we'll get a fix for that put into the next update and then you'll be able to reinstate the setting. Cheers, Dave.

Hi @Joshua T M After some debugging locally it looks like the error is within our currently experimental FAQ index searching functionality. As an immediate workaround you could look to turn off the following experimental setting which should get the search working again. If you could try that out and let me know if that gets you back up and running for now that would be appreciated. In the meantime I'll look to fully replicate the issue within our experimental code and seek to get a fix out for that in the next update. Cheers, Dave.

Hi @Joshua T M Thanks for that, will have another go at replicating. I have an idea of why we may been seeing the error but really needed to try to replicate locally to make sure its fixed. As soon as I can replicate and confirm the fix we'll look to get it applied for you. Cheers, Dave

Hi @Joshua T M Thanks for posting, could you just confirm which portal you are seeing this error in and where exactly (when raising a request or on a search input etc) as I'm currently having trouble replicating the issue. Kind Regards, Dave