Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Cases] Add custom fields: List type #194236

Open
wants to merge 79 commits into
base: main
Choose a base branch
from

Conversation

Zacqary
Copy link
Contributor

@Zacqary Zacqary commented Sep 26, 2024

Summary

Closes #176491

Adds the List custom field type to Cases. Also makes some changes to the custom field configuration type system to handle the new features added in this field type.

The List field type creates a <select> dropdown with a set of options determined by the custom field's configuration. Options are defined as { key: UUID, label: String }.

When the user selects a value, it is saved to the case with the schema { key: ${Field UUID}.{Option UUID}, label: Option Label }. When fetching the case, this key is transformed into a {key: Field UUID, value: Option UUID} pair so that the UI can fetch current option label from the field configuration schema. Therefore, option labels can be renamed and display their correct label in the UI, but updating the label in the case SavedObject will still require a followup issue. Fortunately the only thing this affects is sorting, which is not yet implemented at the UI level for any custom field type.

This PR also allows List fields to be filtered. This required a change from using static filterOptions in custom field configurations to a dynamic getFilterOptions function. The Toggle field was updated to use this new dynamic function.

Screenshot 2024-09-26 at 5 33 26 PM Screenshot 2024-09-26 at 5 32 22 PM

Known Issues

Due to elastic/eui#8027 drag-and-drop on the new <OptionsField> doesn't correctly render the current draggable element inside the flyout. EUI is aiming to fix this before 8.16. UPDATE: This should be fixed

Screenshot 2024-09-26 at 5 42 38 PM

Checklist

@Zacqary Zacqary added release_note:enhancement Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v9.0.0 Feature:Cases Cases feature v8.16.0 backport:version Backport to applied version labels labels Sep 26, 2024
@obltmachine
Copy link

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

  • /oblt-deploy : Deploy a Kibana instance using the Observability test environments.
  • run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

Copy link
Contributor

@adcoelho adcoelho left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please also update the tests in x-pack/test/cases_api_integration/security_and_spaces/tests/common/cases to include examples of list custom fields?

const CaseCustomFieldListWithValidationRt = rt.strict({
key: rt.string,
type: CustomFieldListTypeRt,
value: rt.union([CaseCustomFieldListWithValidationValueRt('value'), rt.null]),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure this is the right approach. Why not just save the key?

Testing this with the API led me to some weird scenarios.

Try the following:

  1. Create a list custom field with a few different options.
  2. Send a case POST request where the custom field value has:(1) a correct key, and(2) a wrong value/label.

The case detail page renders the correct label but the case GET API returns the wrong label that does not exist in the configuration.

Some screenshots illustrating this scenario:

My configuration

Screenshot 2024-12-04 at 15 45 39

The POST request

Screenshot 2024-12-04 at 15 47 12

The case detail page

Screenshot 2024-12-04 at 15 48 12

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure this is the right approach. Why not just save the key?

Already decided on in #168378

Text of the custom field labels need to be searchable and queryable

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Send a case POST request where the custom field value has:(1) a correct key, and(2) a wrong value/label.

Let me take a look and see if I can get the POST to only contain the key and derive the label from it on the server side. That's probably the safest.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For type system simplicity it looks like the easiest solution is to validate both that the correct key exists and that the label matches the key.

@js-jankisalvi
Copy link
Contributor

Found an issue in continuation to what @adcoelho found while deleting an option. Once the option which was selected as defaultValue is deleted, the next option is set as default in custom field. However it is not visible when case is created.
Fixed in 3166029 and also added validation for this on the server

works fine 👍

Required list custom fields do not seem to work properly with the case action and templates.

++
Some weird behaviour with custom fields with value in the template as well (both required and optional). It seems to take wrong list value while creating a case with the template.

custom_field_with_template.mov

Copy link
Contributor

@js-jankisalvi js-jankisalvi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code changes LGTM except some minor comments.
Agree with @adcoelho's concern about saving the option key instead of value for case's custom field.

x-pack/plugins/cases/common/types/api/custom_field/v1.ts Outdated Show resolved Hide resolved
x-pack/plugins/cases/common/types/domain/configure/v1.ts Outdated Show resolved Hide resolved
x-pack/plugins/cases/public/api/utils.ts Outdated Show resolved Hide resolved
type: customFieldsConfigurationMock[5].type,
value: null,
},
...customFieldsConfigurationMock.map(({ key, type, defaultValue, required }) => ({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for doing this! 😄

// When updating the field, store the selected value while waiting for the response
// Display the selected value in the view component while waiting, and only switch it back to the
// previous value if the response fails
const [optimisticDisplayField, setOptimisticDisplayField] = useState<CaseCustomFieldList | null>(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice name 😄 Does it take lot of time to get response here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It takes a couple seconds, not long but long enough to bother me personally 🤣

@Zacqary
Copy link
Contributor Author

Zacqary commented Dec 12, 2024

@adcoelho @js-jankisalvi I also had concerns about saving the option key and the label instead of just saving the option key. As per @cnasikas's comment here this is the schema we have to use on this feature.

@Zacqary Zacqary requested a review from adcoelho December 16, 2024 20:41
…ustom-field

# Conflicts:
#	x-pack/platform/plugins/shared/cases/common/types/api/configure/v1.ts
#	x-pack/platform/plugins/shared/cases/common/types/domain/configure/v1.ts
#	x-pack/platform/plugins/shared/cases/public/components/custom_fields/toggle/configure_text_field.test.ts
#	x-pack/platform/plugins/shared/cases/public/components/custom_fields/toggle/configure_toggle_field.test.ts
#	x-pack/platform/plugins/shared/cases/server/custom_fields/list.ts
#	x-pack/platform/plugins/shared/cases/server/services/cases/transform.ts
#	x-pack/plugins/cases/public/components/custom_fields/toggle/configure_text_field.test.ts
@elasticmachine
Copy link
Contributor

elasticmachine commented Dec 26, 2024

💔 Build Failed

Failed CI Steps

History

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:version Backport to applied version labels Feature:Cases Cases feature release_note:enhancement Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v8.18.0 v9.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Cases] Custom fields: List type
8 participants