[Cases] Allow to add additional fields to IBM resilient connector by janmonschke · Pull Request #236144 · elastic/kibana

janmonschke · 2025-09-23T15:28:09Z

Summary

Allows to send additional properties via the IBM resilient connector

Fixes #213890, Fixes #213896

How to test

Set up the IBM resilient connector and enable it
Create a new case and add {"test_text":"test"} to Additional fields
Save the case and check that the field exists in IBM resilient
Go back to the case in Kibana, update the additional fields, push the update and check that the new value is present in IBM resilient

(Advanced):

Try setting one of these values:

{
    "testing": "test",
    "test_text": "the text",
    "test_boolean": true,
    "test_number": 123,
    "test_date_picker": 2390748293,
    "test_date_time_picker": 2390748298,
    "test_select": 4,
    "test_multi_select": [1,3],
    "test_text_area": ""
}

Try setting test_select or test_multi_select. They are values that are validated on the server.

x-pack/platform/plugins/shared/cases/public/components/connectors/resilient/case_fields.tsx

x-pack/platform/plugins/shared/cases/public/components/connectors/validate_json.ts

elasticmachine · 2025-09-25T14:22:17Z

Pinging @elastic/kibana-cases (Team:Cases)

janmonschke · 2025-09-25T14:23:42Z

x-pack/platform/plugins/shared/actions/server/sub_action_framework/executor.ts

    if (action.schema) {
      try {
-        action.schema.validate(subActionParams);
+        _subActionParams = action.schema.validate(subActionParams) as typeof subActionParams;


@cnasikas This is needed in order to automatically transform the additionalFields string to an object that we can run validations on.

Thanks for fixing that. It makes sense to me.

pmuellr · 2025-09-25T18:42:54Z

Adding new parameters to a Connector typically involves creating an intermediate release, that just includes parameter schema changes. For more info: https://docs.elastic.dev/reops/developer-guide/best-practices-rules#upgrades-and-rollbacks . Note some of the docs only reference rule params, but connector params are affected here as well.

Typically folks will create a PR with JUST the schema changes, and anything else required for them, and nothing else. Get that merged, and running on Serverless. After it's running on Serverless, the rest of the PR can be merged. So there's typically ~ one week delay between these ...

janmonschke · 2025-09-25T18:46:00Z

@pmuellr Could you comment on the pieces of code I'd need to put into a separate PR? Is it just the changes in x-pack/platform/plugins/shared/cases/common/types/domain/connector/v1.ts?

janmonschke · 2025-09-25T18:53:56Z

@pmuellr looking at the slides you linked 👍 If I put the UI behind a feature flag, we should be good as well, right?

pmuellr · 2025-09-25T19:00:51Z

Could you comment on the pieces of code I'd need to put into a separate PR? Is it just the changes in x-pack/platform/plugins/shared/cases/common/types/domain/connector/v1.ts?

Correct. Though typically we don't modify "version" files like a v1.ts, but instead create a v2.ts. Not sure that's required in this case. @cnasikas ?

looking at the slides you linked 👍 If I put the UI behind a feature flag, we should be good as well, right?

Correct. Just more work, as you'll have to deal with the changing the feature flag in a later release to make it the default. :-)

michaelolo24 · 2025-09-29T18:48:33Z

x-pack/platform/plugins/shared/cases/server/config.ts

      enableCaseSummary: schema.boolean({ defaultValue: false }),
    })
  ),
+  resilient: schema.object({


👌🏾 Thanks!

michaelolo24 · 2025-09-29T18:50:29Z

x-pack/platform/plugins/shared/stack_connectors/server/connector_types/resilient/mocks.ts

-export const resilientFields = [
+import type { ResilientFieldMeta } from './schema';
+
+export const resilientFields: ResilientFieldMeta[] = [


x-pack/platform/plugins/shared/stack_connectors/server/connector_types/resilient/resilient.ts

michaelolo24 · 2025-09-29T18:57:19Z

x-pack/platform/plugins/shared/stack_connectors/server/connector_types/resilient/utils.ts

+          givenValues,
+          null,
+          2
+        )}. Accepted values: ${valuesMeta.map((v) => `${v.value} (for "${v.label}")`)}`


Really nice error messaging here to get around the multi-select expectations. Thanks!

michaelolo24 · 2025-09-29T18:58:30Z

x-pack/platform/plugins/shared/stack_connectors/server/connector_types/resilient/utils.ts

+      }
+    case 'datetimepicker':
+    case 'datepicker':
+      return isNumber(value) ? { date: value } : {};


Just confirming this is always expected to be number and doesn't need an additional isDate() conversion/check?

Yep, this is supposed to be a number. Any other value will return a 400 from IBM Resilient

michaelolo24

Nice work, thank you for getting this done so promptly!

cnasikas · 2025-09-30T12:43:12Z

x-pack/platform/plugins/shared/stack_connectors/server/connector_types/resilient/schema.ts

    read_only: schema.boolean(),
    required: schema.nullable(schema.string()),
    text: schema.string(),
+    internal: schema.boolean(),


I am not sure if older versions of Resilient respond with this field. Should we make it optional (nullable) just to be safe?

Removed in 2393254

cnasikas · 2025-09-30T14:29:23Z

x-pack/platform/plugins/shared/stack_connectors/server/connector_types/resilient/utils.ts

+    }
+
+    // Custom fields need to be prefixed with 'properties.'
+    if (fieldMeta.prefix === 'properties') {


I would say not to make any assumptions about how users would put their custom fields. The IBM documentation is clear, so they should put the properties themselves. For example this is what they should put in the editor:

{ "state": 41, "properties": { "foo": "bar" } }

imo, properties is an implementation detail and not necessarily known by the people that will use Kibana cases. I can change the logic to allow arbitrary prefixes if that sounds better?

Done in 2393254 & 6dde18d

cnasikas · 2025-09-30T14:44:17Z

x-pack/platform/plugins/shared/stack_connectors/server/connector_types/resilient/types.ts

  description?: { format: string; content: string };
  incident_type_ids?: Array<{ id: number }>;
  severity_code?: { id: number };
+  properties?: Record<string, unknown>;


We should remove this and add [unknown: string]: unknown, correct?

cnasikas · 2025-09-30T16:08:13Z

x-pack/platform/plugins/shared/stack_connectors/server/connector_types/resilient/utils.ts

-  if (field === 'incidentTypes') {
-    if (isArray(value)) {
-      return { ids: value.map((item) => Number(item)) };
+export function validateValues(


I am a bit concerned that we validate the values. What if an existing rule starts to fail because we started validating the fields?

If an invalid value is supplied, the request to IBM will fail anyways. This is just a way to enhance the editing experience, since customers will have to add id(s) and not labels.

Are we sure that all IBM resilient versions behave the same? Maybe we can fail at everything new but not at the old/existing fields?

You mean only validate fields from the additionalFields?

I was thinking that, yes, to be sure that we do not introduce a breaking change. Maybe I am too cautious. Wdyt?

Sounds sensible to me. Mind if I do that in a follow-up PR?

cnasikas · 2025-09-30T16:09:49Z

x-pack/platform/plugins/shared/stack_connectors/server/connector_types/resilient/utils.ts

      }

+      const fieldMeta = fieldsRecord[name];
+      if (!fieldMeta) {


I am a bit concerned that we validate the values. What if an existing rule starts to fail because we started validating here?

If there is no metadata for that field, we cannot determine the required shape for the update request, which is why we rely on it here.

…-additional-fields

elasticmachine · 2025-10-01T04:27:22Z

💛 Build succeeded, but was flaky

Buildkite Build
Commit: e21bbc3

Failed CI Steps

Test Failures

[job] [logs] FTR Configs #16 / Endpoint plugin @ess @serverless @skipInServerlessMKI test metadata apis list endpoints GET route "after all" hook for "metadata api should return all hosts when filter is empty string"
[job] [logs] FTR Configs #32 / integrations When on the Trusted Apps list "after all" hook for "should be able to add a new trusted app and remove it"
[job] [logs] FTR Configs #99 / security APIs - Session Idle Session Idle cleanup should properly clean up session expired because of idle timeout when providers override global session config

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
`cases`	1173	1174	+1
`stackConnectors`	368	369	+1
total			+2

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
`cases`	1.4MB	1.4MB	+3.0KB
`stackConnectors`	714.0KB	722.7KB	+8.7KB
total			+11.7KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
`cases`	140.8KB	141.0KB	+168.0B
`stackConnectors`	66.3KB	66.7KB	+459.0B
total			+627.0B

History

💚 Build #345402 succeeded b430b41
💔 Build #345382 failed 384bcb1
💔 Build #345376 failed f54740b
💚 Build #344881 succeeded 6178d9b
💔 Build #344771 failed 3317484
💔 Build #344669 failed 123dcf9

cc @janmonschke

cnasikas

LGTM! I tested and it is working as expected. My main concerns are:

Is throwing an error by validating the fields safe? I am concern about the old fields, not the new ones. Does all IBM resilient versions behave the same? Or was a case where some version did not throw an error for the old values?
About the custom fields and prefixing the properties, I do not think it is an implementation detail, because this is how the IBM Rest API docs tell you how to submit custom fields. Also, what if a custom field has the same key as a root field? Users will never be able to set both fields.

cnasikas · 2025-10-01T07:04:24Z

.../platform/plugins/shared/stack_connectors/server/connector_types/resilient/resilient.test.ts

Could you please add some test to cover the new functionality?

elasticmachine · 2025-10-06T15:23:18Z

Pinging @elastic/response-ops (Team:ResponseOps)

…astic#236144) ## Summary Allows to send additional properties via the IBM resilient connector <img width="1252" height="355" alt="Screenshot 2025-09-25 at 16 20 14" src="https://github.com/user-attachments/assets/78bbec79-22d2-47d5-8238-fcb14cfaf887" /> <img width="500" height="162" alt="Screenshot 2025-09-25 at 16 20 37" src="https://github.com/user-attachments/assets/cd615bdb-648d-48a1-ade0-8c8db1977d01" /> Fixes elastic#213890, Fixes elastic#213896 ### How to test - Set up the IBM resilient connector and enable it - Create a new case and add `{"test_text":"test"}` to `Additional fields` - Save the case and check that the field exists in IBM resilient - Go back to the case in Kibana, update the additional fields, push the update and check that the new value is present in IBM resilient **(Advanced)**: Try setting one of these values: ```json { "testing": "test", "test_text": "the text", "test_boolean": true, "test_number": 123, "test_date_picker": 2390748293, "test_date_time_picker": 2390748298, "test_select": 4, "test_multi_select": [1,3], "test_text_area": "" } ``` Try setting `test_select` or `test_multi_select`. They are values that are validated on the server. --------- Co-authored-by: Michael Olorunnisola <michael.olorunnisola@elastic.co>

janmonschke added 2 commits September 23, 2025 17:09

add schema and UI changes

daf26bb

more UI and logic changes

4fcda76

janmonschke self-assigned this Sep 23, 2025

janmonschke added release_note:enhancement backport:skip This PR does not require backporting Team:Cases Security Solution Cases team labels Sep 23, 2025

michaelolo24 reviewed Sep 24, 2025

View reviewed changes

x-pack/platform/plugins/shared/cases/public/components/connectors/resilient/case_fields.tsx Outdated Show resolved Hide resolved

michaelolo24 reviewed Sep 24, 2025

View reviewed changes

x-pack/platform/plugins/shared/cases/public/components/connectors/validate_json.ts Outdated Show resolved Hide resolved

janmonschke added 9 commits September 24, 2025 08:40

validateJSON -> generateJSONValidator

f399c53

fix tests

a58196b

fix more tests

f2b7295

add additional fields (validation still missing)

180966b

use properties field

86283c4

it's actually a string

c29dada

fix tests and make updates work

9cc8599

fix tests

2637833

proper parsing of schema to avoid manual JSON.parse

c7e5057

janmonschke marked this pull request as ready for review September 25, 2025 14:22

janmonschke requested review from a team as code owners September 25, 2025 14:22

janmonschke changed the title ~~[IN PROGRESS][Cases] Allow to add additional fields to IBM resilient connector~~ Sep 25, 2025

janmonschke commented Sep 25, 2025

View reviewed changes

janmonschke added 3 commits September 25, 2025 19:47

fix tests

001b0a8

Merge branch 'main' into cases/ibm-resilient-additional-fields

a334d82

two more tests

9fe2a77

janmonschke added 2 commits September 29, 2025 20:29

max 50

b36b2ee

Merge branch 'main' into cases/ibm-resilient-additional-fields

cb14e80

michaelolo24 reviewed Sep 29, 2025

View reviewed changes

x-pack/platform/plugins/shared/stack_connectors/server/connector_types/resilient/resilient.ts Show resolved Hide resolved

michaelolo24 reviewed Sep 29, 2025

View reviewed changes

michaelolo24 approved these changes Sep 29, 2025

View reviewed changes

janmonschke added 3 commits September 29, 2025 21:40

Merge branch 'main' into cases/ibm-resilient-additional-fields

f54740b

fix types

384bcb1

fix types

b430b41

janmonschke mentioned this pull request Sep 30, 2025

[DRAFT][Cases] Improve ibm resilient form #236830

Closed

1 task

cnasikas reviewed Sep 30, 2025

View reviewed changes

janmonschke and others added 3 commits September 30, 2025 19:06

remove internal and rely on prefix

2393254

remove properties

6dde18d

Merge remote-tracking branch 'upstream/main' into cases/ibm-resilient…

e21bbc3

…-additional-fields

cnasikas approved these changes Oct 1, 2025

View reviewed changes

do not throw for unknown fields

d03c456

janmonschke enabled auto-merge (squash) October 1, 2025 13:53

janmonschke added v9.2.0 backport:version Backport to applied version labels and removed backport:skip This PR does not require backporting labels Oct 1, 2025

janmonschke merged commit 76e6d95 into elastic:main Oct 1, 2025
17 checks passed

kibanamachine added backport:skip This PR does not require backporting and removed backport:version Backport to applied version labels labels Oct 1, 2025

jmikell821 added the Team:ResponseOps Platform ResponseOps team (formerly the Cases and Alerting teams) t// label Oct 6, 2025

janmonschke mentioned this pull request Oct 14, 2025

[Internal]: [Cases] Added a new form field additional fields elastic/docs-content#3469

Closed

Conversation

janmonschke commented Sep 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

How to test

Uh oh!

Uh oh!

elasticmachine commented Sep 25, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pmuellr commented Sep 25, 2025

janmonschke commented Sep 25, 2025

janmonschke commented Sep 25, 2025

pmuellr commented Sep 25, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

michaelolo24 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janmonschke Sep 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cnasikas Oct 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

elasticmachine commented Oct 1, 2025

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

Metrics [docs]

Module Count

Async chunks

Page load bundle

History

cnasikas left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Uh oh!

elasticmachine commented Oct 6, 2025

Labels

9 participants

janmonschke commented Sep 23, 2025 •

edited

Loading

janmonschke Sep 30, 2025 •

edited

Loading

cnasikas Oct 1, 2025 •

edited

Loading