[Cases] Filter & paginate cases activity

[cnasikas]

Cases show the activity (user actions) of the case. At the moment, we fetch all users' actions and show them in the case's activity. To aid users to find quicker information related to a case we should a) allow filtering the activity list based on the type of activity (alerts, user comments, etc) and b) support pagination. To achieve that we need to create API endpoints that support filtering and pagination on comments and user actions.

Cases UI gets the fields of the connectors from the user actions. It traverses through all user actions to find the fields of the selected information and indicates to the user if the case needs to be pushed. By introducing filtering and pagination the UI cannot deduct the needed information about connectors. For that reason, we need to provide the information needed by the UI on the backend. An internal endpoint should be created that returns all fields of all connectors attached to the case plus if the case needs to be pushed.

Task items

• Create internal API GET /internal/cases/<case_id>/connectors ([Cases] Provide connector's information from the backend  #134346, [Cases] API to return a case's connectors information #147295)
• Get connectors' information in the UI from the new connector's endpoint ([Cases] Update UI to use the new connector's API #149276)
• Create public GET /api/cases/user_actions/_find ([Cases] Create new endpoints to replace the deprecated ones. #134344, [Cases] Adding _find API for user actions #148861)
• Create internal API GET /internal/cases/<case_id>/attachments/_bulk_get ([Cases] Add bulk get attachments API #149269)
• Create case activity stats internal API GET /internal/cases/<case_id>/user_actions/_stats ([Cases] Provide case's stats information from the backend #149390)
• Create case activity users internal API GET /internal/cases/<case_id>/user_actions/_users ([Cases] Create internal endpoint to get all participants of the case #149663)
• Get the user information in the UI from the new users' endpoint ([Cases] Use the new internal users API in the UI #150432)
• Filter case activity in the UI ([Cases] Filter case activity #149191, [Cases] Filter and sort case activities #149396)
• Paginate case activity in the UI ([Cases] Paginate user actions #130227, [Cases] Filter user activities pagination #152702)

Related issues: #130227, #134346, #134344, #115730, #117904, #149191

[elasticmachine]

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

[jonathan-buttner]

@cnasikas for the bulk get attachments, should it allow retrieving attachments from multiple cases in a single request? I doubt we'd use it in the UI any time soon but it's trivial to support that functionality.

Also how about:

POST /internal/cases/attachments/_bulk_get

Using a post so we can support retrieving 10k attachments in one go and attachments to keep inline with the bulk create.

[cnasikas]

Hmm interesting, my initial thought was to be per case like the _find. For example, POST /internal/cases/<case_id>/attachments/_bulk_get (I forgot to update the description. Sorry for that). It is easier to do validations/authorization per case and very trivial to change to support all documents later. If it was a public one what would you do?

Using a post so we can support retrieving 10k attachments in one go and attachments to keep inline with the bulk create.

Good catch!

[jonathan-buttner]

Following up here, we talked as a team and we're going to go with only retrieving the comments for a particular case for now and expand it in the future if we need to.