[Cases][Meta] Road to versioned HTTP APIs #153726
Assignees
Labels
Feature:Cases
Cases feature
Meta
Project:Serverless
Work as part of the Serverless project for its initial release
Team:ResponseOps
Label for the ResponseOps team (formerly the Cases and Alerting teams)
Comments
cnasikas
added
Meta
Team:ResponseOps
|
Pinging @elastic/response-ops (Team:ResponseOps) |
|
Pinging @elastic/response-ops-cases (Feature:Cases) |
This was referenced Apr 20, 2023
jonathan-buttner
added a commit
that referenced
this issue
Apr 26, 2023
…e layer (#155325) This PR separates the http API io-ts types from the types that are used in the cases service layer to interact with the saved object client. This PR is specifically for the user actions it only affects the types used when interacting with the saved object client and doesn't touch the transformation logic yet. Issue: #153726
jonathan-buttner
added a commit
that referenced
this issue
Apr 26, 2023
This PR separates the http API io-ts types from the types that are used in the cases service layer to interact with the saved object client. This PR is specifically for the attachments it only affects the types used when interacting with the saved object client and doesn't touch the transformation logic yet. Issue: #153726
This was referenced Apr 27, 2023
jonathan-buttner
added a commit
that referenced
this issue
Apr 27, 2023
This PR separates the http API io-ts types from the types that are used in the cases service layer to interact with the saved object client. This PR is splits up the remaining types within the service layer (configure and connector mappings). Issue: #153726
jonathan-buttner
added a commit
that referenced
this issue
Apr 28, 2023
This PR separates the persisted SO attributes from the fields received in the HTTP API requests. This is to address step 2 in preparing our HTTP routes as versioned. Issue: #153726 This PR encompasses a few PRs here which have been reviewed individually by the cases team members: #155325 - User actions #155440 - Attachments #155444 - Configure, Connector Mappings #155277 - Cases The large number of files is because of renaming some types throughout the frontend code. There shouldn't be many functionality changes, mostly just type changes. --------- Co-authored-by: Christos Nasikas <christos.nasikas@elastic.co> Co-authored-by: Patryk Kopyciński <contact@patrykkopycinski.com>
Merged
2 tasks
cnasikas
added a commit
that referenced
this issue
Jun 2, 2023
…imageUrl` is set to `null` (#158815) ## Summary As part of the Serverless work in #153726, we validate all of our responses returned by the Cases APIs. The GET case users internal API validates the schema of the `avatar` persisted in the `data` of the user profile. It may be possible to set the `imageUrl` to `null` from within the user profile page. This PR fixes this bug. It also updates the type of the `imageUrl` in `UserProfileAvatarData`. ## Testing 1. Go to your user profile and press save 2. Go to a case 3. You should see an error toaster. The fix in this RP should eliminate the error toaster and the Case view page should be shown properly 4. Go to your user profile and change the initials the color and set a profile image. Go again to a case and verify that the avatar is shown as expected ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
cnasikas
added
the
Project:Serverless
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To not introduce any breaking changes or changes in the behavior of the Kibana UI or the Cases endpoints when upgrading Kibana, we need to do changes in our endpoints. The needed steps to achieve this goal are described in the following section.
Steps
Disconnect API Interface with SO Attributes
The goal of this step is to isolate the SO attributes from the HTTP APIs. Any change in our SO attributes should not reflect a change in our API interfaces. To do that we need to:
PRs for this step:
CasesUItoCasesFindResponseUI#156536Strict input validation
Our HTTP APIs must have the final say about acceptable data. The APIs should validate any data like query parameters, path parameters, or body requests. For this step, we need to do the following:
io-ts'sstrictutility type to ignore excess fields #156156 ([Cases] Update io-ts types as strict #156813) (@js-jankisalvi)io-tsas much as possible ([Cases] Guardrails in Cases APIs #146945) (@adcoelho @js-jankisalvi)io-tsin all case services (@cnasikas) ([Cases] Validate attributes before create SOs #158590)Keep APIs Narrow
As in Step 2, the goal of this step is to isolate the SO attributes from the HTTP APIs. This means that we should not allow consumers of our APIs to reference directly to our SO attributes.
fieldsparams and return a subset of theCasefields. #156364 (@cnasikas) ([Cases] Removefieldsparam from the bulk get cases internal API #156366)searchFieldsonly to the title and the descriptionsortFieldto:title,category,createdAt,updatedAt,closedAt,status, andseverityrootSearchFieldsVersion HTTP APIs
configuredomain object and API #160605)casesandcommentdomain and apis #161954)casesandcommentdomain and apis #161954)user_actiondomain and apis #161783)casesandcommentdomain and apis #161954, [Cases] Version attachment routes types #163081)connectorsdomain and apis #162059)metricsAPI types #162817)modelVersionon theregisterTypeAPI to specify up and down transforms for all cases saved objectsUI
The text was updated successfully, but these errors were encountered: