-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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] Custom fields: List type #176491
Comments
Pinging @elastic/response-ops (Team:ResponseOps) |
Pinging @elastic/response-ops-cases (Feature:Cases) |
Working on implementing this with the schema of |
I would advise keeping the |
From the research issue:
This helps us easily display the correct label text in the UI, but it won't correctly update the label if the user changes it in the field configuration. For example:
With the research issue's implementation, we would still be displaying
We can conceivably hack |
Hey @Zacqary! Great question. If you see this issue in the "Out of scope" section, renaming will not supported. So feel free to ignore this scenario at the moment. In the research issue, the "B. Option Renaming" section describes how we want to do renaming in the future. While we can show the configuration's value on the UI this will be misleading as the data will be different and filtering or sorting will not work as expected (users will see a different value in the UI than the actual data where the filtering or sorting is performed in the cases table). |
@cnasikas Got it, sorry I was so focused on reading the research issue I completely missed the out of scope section for this one |
Actually implementing this schema is proving problematic: "customFields": [
{ "type": "list", "key": "department.engineering", "value": ["Super Awesome Eng"] }
{ "type": "list", "key": "department.sales", "value": ["Sales"] }
] There's several layers of APIs in both the form library and the SavedObject parsing libraries that result in:
However, I've managed to get this schema working perfectly: "customFields": [
{ "type": "list", "key": "department", "value": ["engineering", "Super Awesome Eng"] }
{ "type": "list", "key": "department", "value": ["sales", "Sales"] }
] There's an open question in the research issue asking if we need to set both the @cnasikas Do you think the above schema ( |
As per Zoom discussion with @cnasikas, I was able to transform requests from the UI to successfully save a schema of: { "type": "list", "key": "department.engineering", "value": ["Super Awesome Eng"] } The problem I'm now facing is that none of the rest of the existing custom field logic is able to handle dot notation in keys.
In working on implementing this, I've realized it's problematic to save the selected I'm going to work on implementing the following schema: { "type": "list", "key": "department", "value": "engineering" } and to add an additional layer on the UI to pull the current |
@Zacqary About the following schema:
We thought about it when we researched but it cannot work with searching and sorting. Imagine that the keys can be anything like
The transformation of this schema needs to happen on the backend before storing it in the SO. I would suggest the following:
On the way back it will be the opposite.
Only the Cases Service is aware of the dot notation. The cases client, the APIs, and the UI should not be aware of this implementation detail (dot notation) and I think all the issues you may face will be eliminated. |
Summary
In issue #168378 research was done on how to support the list custom field type in cases. We should follow the research issue to implement the list custom field.
DoD
single-list
. Users can define a list of available options a user can select. The field can be required and a default value can be selected.Out of scope
Research issue: #168378
The text was updated successfully, but these errors were encountered: