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.

Sign up for GitHub

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

Jump to bottom

[Cases][Meta] Road to versioned HTTP APIs #153726

Open
23 of 30 tasks
cnasikas opened this issue Mar 25, 2023 · 2 comments
Open
23 of 30 tasks

[Cases][Meta] Road to versioned HTTP APIs #153726

cnasikas opened this issue Mar 25, 2023 · 2 comments
Assignees
@adcoelho @cnasikas @jonathan-buttner @js-jankisalvi
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
Copy link
Member

cnasikas commented Mar 25, 2023 •
edited
Loading

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:

  • Create types for domain objects. For example, Cases, Comments, etc (@cnasikas @jonathan-buttner)
  • Create TS interfaces/types for SOs and HTTP routes even if they are the same. Types for SOs should be in the server directory (@cnasikas @jonathan-buttner)
  • Explicitly map the SO attributes to the response and vice-versa even if they are the same. No more spreading (@cnasikas @jonathan-buttner)

PRs for this step:

Strict 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:

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.

Version HTTP APIs

UI
@cnasikas cnasikas added Meta Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) Feature:Cases Cases feature labels Mar 25, 2023
@elasticmachine
Copy link
Contributor

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

@elasticmachine
Copy link
Contributor

Pinging @elastic/response-ops-cases (Feature:Cases)

@cnasikas cnasikas mentioned this issue Mar 27, 2023
Closed
@lukasolson lukasolson mentioned this issue Apr 12, 2023
Merged
This was referenced Apr 20, 2023
Merged
Merged
Merged
jonathan-buttner added a commit that referenced this issue Apr 26, 2023
@jonathan-buttner
[Cases] Separating http request contract from saved object persistenc…
ed3d037 
…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
@jonathan-buttner
[Cases] Split attachment types for versioned http apis (#155440)
9f9eb79 
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
Closed
Closed
jonathan-buttner added a commit that referenced this issue Apr 27, 2023
@jonathan-buttner
[Cases] Split remaining cases types (#155444)
4ea7182 
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 jonathan-buttner mentioned this issue Apr 27, 2023
Merged
jonathan-buttner added a commit that referenced this issue Apr 28, 2023
@jonathan-buttner @cnasikas @patrykkopycinski
[Cases] Separate Cases SO attributes from HTTP APIs (#155898)
6d5e245 
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>
@cnasikas cnasikas mentioned this issue May 8, 2023
Closed
@cnasikas cnasikas mentioned this issue Jun 1, 2023
Merged
2 tasks
cnasikas added a commit that referenced this issue Jun 2, 2023
@cnasikas
[Cases] Fix bug where the Cases users API will thrown an error when `…
7205072 
…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)
cqliu1 pushed a commit to cqliu1/kibana that referenced this issue Jun 5, 2023
@cnasikas @cqliu1
[Cases] Fix bug where the Cases users API will thrown an error when `…
b80a717 
…imageUrl` is set to `null` (elastic#158815)

## Summary

As part of the Serverless work in
elastic#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)
sloanelybutsurely pushed a commit to sloanelybutsurely/kibana that referenced this issue Jun 6, 2023
@cnasikas
[Cases] Fix bug where the Cases users API will thrown an error when `…
8fcc128 
…imageUrl` is set to `null` (elastic#158815)

## Summary

As part of the Serverless work in
elastic#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 cnasikas mentioned this issue Jun 21, 2023
Merged
2 tasks
@cnasikas cnasikas added the Project:Serverless Work as part of the Serverless project for its initial release label Jun 21, 2023
@adcoelho adcoelho mentioned this issue Jul 24, 2023
Closed
@cnasikas cnasikas mentioned this issue Aug 3, 2023
Merged
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@adcoelho adcoelho

@cnasikas cnasikas

@jonathan-buttner jonathan-buttner

@js-jankisalvi js-jankisalvi

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)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@adcoelho @cnasikas @elasticmachine @jonathan-buttner @js-jankisalvi