This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Some issues with the update to Service Catalog and Custom Fields.

I wanted to post a discussion in case anyone else is seeing issues with the update, so there's a place collaborate. I'm also going to be opening a support ticket.

This morning, we noticed that a number of our forms had their Conditional Logic broken by the update. The affected process actions seem to be fields that used to be Dynamic Dropdowns. You can tell those by the fields that now have "Logic" written next to them.

This is an example of what one of the broken conditionals looks like:

Instead of targeting the new Custom Field called "Corporate Role", it looks to be targeting an old record ID instead. This didn't impact every previous Dynamic Dropdown, only some of them. I'm still working on identifying a pattern.

There are hints that there may be other issues, such as options having been removed from Dropdowns. I'll continue to post any other breakage/information I find in this discussion. Please also comment with anything you've found that might be an issue caused by the new update. It should help everyone track down potential issues before our users find them.

Thanks all!

  • Hi , thanks for starting this thread and bringing this to our attention. We have received a couple reports of this happening to customers and I first want to say, sorry that it happened. We obviously aim to not have these types of things happen during releases but sometimes we miss the mark. Our engineering team is looking into these issues and we would love for you, and anyone else, to continue to open support tickets so we can investigate more and more. 

    I'll be on the lookout for your ticket so I can make sure the engineers get their eyes on it. 

    Thanks,

    Joey

    Senior Product Manager

  • Update: API Mapping of Request Variables is now broken.

    The "request_variables" array received from making a GET request on https://api.samanage.com/incidents.json?layout=long for Service Requests is now an empty array. All of the previous "request_variables" are now listed under the "custom_field_values" array.

    This is contrary to the expected behavior:

    SolarWinds Service Desk April 2022 Release Notes

  • It's not too bad to update your code to support the custom fields since they're both formatted as Lists of Dictionaries. Just make sure to keep code in to support the "request_variables" as older tickets will still have these values.

    Another thing to note is that some of the field values from the API are in different formats in custom fields than they were in request variables. An example would be the date format:

    request variable format: 2022-04-01

    custom field format: Apr 01, 2022

  • Hi Joey, I appreciate your fast response on here.

    If there are any other known issues that customers are reporting in, it would be much appreciated if you or another rep could comment or link to them here to raise awareness.

    Thank you!

  • RESOLVED: API Bug: Custom Fields now show up twice in the "custom_fields_values" JSON object

    The "custom_fields_values" array returns two of each custom_fields. So if your form has two custom fields, "Summary" and "Detailed Description", the returned json will look like:

    {
        ...
    	"custom_fields_values": [{
    		"id": 123456789,
    		"custom_field_id": 123,
    		"name": "Summary",
    		"value": "This is a summary",
    		"attachment": null,
    		"options": "",
    		"type": 6,
    		"type_name": "Text_Area",
    		"entity": null,
    		"user": null
    	}, {
    		"id": 987654321,
    		"custom_field_id": 456,
    		"name": "Detailed Description",
    		"value": "This is a detailed description"
    	}, {
    		"id": 123456789,
    		"custom_field_id": 123,
    		"name": "Summary",
    		"value": "This is a summary",
    		"attachment": null,
    		"options": "",
    		"type": 6,
    		"type_name": "Text_Area",
    		"entity": null,
    		"user": null
    	}, {
    		"id": 987654321,
    		"custom_field_id": 456,
    		"name": "Detailed Description",
    		"value": "This is a detailed description"
    	}]
    	...
    }

    Note that I've truncated this for readability.

    I checked service catalog items submitted before 4/3 and after 4/3 and the bug was introduced with this update.

  • Update: Form Logic doesn't work in "Convert to Service Request" prompt

    The "Change Type" controls whether one of the three fields in the below form should be shown. This is a simple example form, but in this screenshot, we should only see the "Restore Access" text field.

  • This is a big issue when "required" fields are supposed to be hidden, since you can't submit without filling them out.

  • It looks like this is only happening in Service Requests and not standard incidents

  • Thanks for the running list Mitch! I just checked with engineering and it looks like they are working through these issues. The main one they are working on right now is correcting the issues of the UUID showing up in conditions which I was just told they have completely resolved!

    After they resolve that, we are dedicating efforts in resolving these other issues. 

    Thanks

    Joey Brown

  • Hi Mitch, just got an update from engineering, that you'll probably also get in your support ticket soon, that they are testing a fix for this now. If everything passes then we can expect it in the next deploy.