bug? How can I clear the value in a custom field?

[Gareth Cantrell]

I have a custom field (h_custom_59) in a Service Request and have exposed the field in the Service Request form as a "Single Line Text Field".

If I edit the details section and change the value in the custom field, I can save it and the field updates with the new value.

If I delete the value and then click "Save", the field is not cleared and remains in the database after clicking Save and still shows the previous value in the form

EDIT: this appears to only affect custom fields 41 and above.

Edited August 28 by Gareth Cantrell
clarification after further tests

[Gareth Cantrell]

The only way I have been able to clear the value is to send the following API update using data::entityUpdateRecord

{
  "@service": "data",
  "@method": "entityUpdateRecord",
  "params": {
    "application": "com.hornbill.servicemanager",
    "entity": "ServiceRequests",
    "primaryEntityData": {
      "record": {
        "h_fk_reference": "SR00020462",
        "h_custom_59": ""
      }
    }
  }
}

Surely there should be a way of clearing a field from the UI without needing to resort to API calls?

[AlexOnTheHill]

Does the creation of a custom button help here?

You should be able to set an auto task to apply an update to any custom field.

To my mind though custom buttons should be an exceptional circumstance tool and regular deletion and saving the value from the request details should work.

[Gareth Cantrell]

I tried using an Update Request -> Custom fields automation node, and that doesn't clear the field either.

I set the value to "Manual" and left the value empty and I also tried with the value set to "Auto" - neither works to clear the field.

I also tried using the API to update the "RequestsExtended" entity, and that doesn't work either.

[AlexOnTheHill]

I would like to see this looked into further then because my Major Incidents process uses a custom button to set a value and we have a revoke MI button which is used to manually erase this value.

I'm going to create a test auto-task to add a value and take it away to see what happens.

[Berto2002]

Because of the unreliability of 'clearing' a value from a custom field I suggest setting 'starting' values on logging for custom fields you later need to change. E.g. the starting value set by workflow could be the assumed state of "noMI" for custom x. One custom button then sets to "yesMI" and the other resets to "noMI". Then you do not depend on the null or empty criteria.

I do the same for integer fields to start at "1" and date fields to start at Dec 27 1997 (date star wars was released in the UK)

[AlexOnTheHill]

Just did a quick test with an autotask that sets a custom d value if not already set and unsets the custom d value if it is set.

Then created a custom button to show if the owner was me and custom d is set and a different button if the owner was me and the custom d wasn't set.

Fortunately, picking a request and pressing the button once removed the first button I created and showed the second button meaning it did successfully set and unset the value of custom d.

For the set branch

For the unset branch

All looks good to me

[Gareth Cantrell]

I've just done some extra tests, and as I suspected, it is only affecting custom fields 41+ (i.e. the extra custom fields which were added in October last year).

Custom fields 40 and below behave as expected.

[AlexOnTheHill]

I've just tested with Custom 41 and can confirm using the same setup as earlier, just changing the which custom value is being updated. The auto task can add the value but not remove it.

[Gareth Cantrell]

To summarise: the following API methods are unable to clear custom fields 41 or greater:

• apps/com.hornbill.servicemanager/Requests::update <- (this is the official documented API to update custom fields and what the UI uses as well)
• data::entityUpdateRecord (using entity: RequestsExtended)

the following API call is the only way to clear custom fields 41 or greater:

• data::entityUpdateRecord (using the request-specific entity, i.e. entity=ServiceRequests, entity=Incidents, etc)

Custom fields below 40 and below work as expected.

I expect the BPM automation to update custom fields is probably using the Requests::update API as well which is why it's not working.

[CraigP]

7 minutes ago, Gareth Cantrell said:

To summarise: the following API methods are unable to clear custom fields 41 or greater:

• apps/com.hornbill.servicemanager/Requests::update <- (this is the official documented API to update custom fields and what the UI uses as well)
• data::entityUpdateRecord (using entity: RequestsExtended)

the following API call is the only way to clear custom fields 41 or greater:

• data::entityUpdateRecord (using the request-specific entity, i.e. entity=ServiceRequests, entity=Incidents, etc)

Custom fields below 40 and below work as expected.

I expect the BPM automation to update custom fields is probably using the Requests::update API as well which is why it's not working.

Interesting find. I was going to say I've noticed the issue of fields not updating when cleared in the Details section before, but hadn't clocked it was only on certain fields.

It's been a while since I've looked at clearing custom fields via the BPM. Just did a little bit of testing again now and I see setting manual and no value does seem to work as expected with Custom A-T (for reference I tested C, O and P). However the inability to clear Custom 38/39 has been a source of frustration for me in the past, and I've tested these too and they do not seem to clear. So one assumes any custom fields only present in the extended table (31+) don't work then.

That said, the date (21-25) and integer (26-30) fields don't seem to clear either, but this might be a bit more understandable when they're expecting a specific type of data. I imagine they don't like being provided a null value (but obviously it should still be possible to clear these fields when needed!).

[AlexOnTheHill]

I raised the issue of not being able to unset custom fields 41 upward with Hornbill directly.

They have confirmed that this is unexpected behaviour and have passed it to developers to have resolved in a future release.