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] Integrating file service and registering file kinds #152031

Merged
merged 29 commits into from
Mar 2, 2023

Conversation

jonathan-buttner
Copy link
Contributor

@jonathan-buttner jonathan-buttner commented Feb 23, 2023

This PR registers three file kinds for cases. One for each instance of cases (stack, observability, and security). Each solution needs separate http tags for the routes that are generated by the file service to implement RBAC.

I refactored the logic to remove some duplication across the three plugins since we're essentially registering the same http tags with slightly different names.

This PR shouldn't affect any of the current functionality.

Notable changes:

  • I split up the constants.ts file, really the only change is adding the file kinds logic to generate the http tags the rest is copy/paste
  • Refactored the logic to generate the api http tags for each plugin
  • Registered the three file kinds

Issues: #151780 #151933

@jonathan-buttner jonathan-buttner added release_note:skip Skip the PR/issue when compiling release notes backport:skip This commit does not require backporting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) Feature:Cases Cases feature v8.8.0 labels Feb 23, 2023
for (const plugin of OWNERS) {
it(`should create and delete a file for plugin: ${plugin}`, async () => {
const createResult = await supertest
.post(FILES_API_ROUTES.fileKind.getCreateFileRoute(plugin))
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 trying to understand all this so please bear with me 😄

I get that our intent is

cases will register a unique file kind of each owner type.

and

On the UI when the user interacts with the files page to request all the files or view them, cases will deduce which plugin we are operating within and use that particular file kind for finding/opening the files.

Above, in x-pack/plugins/cases/common/constants/files.ts the HTTP tags were built but in these tests, all we are doing is calling FILES_API_ROUTES.fileKind.get*FileRoute(plugin)
which is something that is already provided by the files team(?) and already takes into account the plugin.

Is it precisely because you did registerCaseFileKinds that this now works? Otherwise, it wouldn't recognize the plugins?

And here the kind passed is only the plugin but in x-pack/plugins/cases/common/constants/files.ts it seems way more complicated. ${owner}FilesCases${operation}.

How does the API match plugin => ${owner}FilesCases...(left out the operation because I assume it comes from get*FileRoute)?

charlie

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Haha no worries

Is it precisely because you did registerCaseFileKinds that this now works? Otherwise, it wouldn't recognize the plugins?

That's correct, he have to call their filesSetupPlugin.registerFileKind function to register the 3 owners otherwise we'd get an error if we tried to access routes for that kind because the routes wouldn't be created. I pass this function to a utility because we need to do it on the frontend and backend.

And here the kind passed is only the plugin but in x-pack/plugins/cases/common/constants/files.ts it seems way more complicated. ${owner}FilesCases${operation}.

Yeah so the http tags get used in two places. When registering the file kind to dictate which tags are need to use those routes (aka securitySolutionFilesCasesRead for the list, getById, download etc). Then we specify those http tags in this file: https://github.com/elastic/kibana/pull/152031/files#diff-ae9053bde29ec5baa7141b8c10a47c997d4c87319993f3c5a206ec9239956640R55

So when a user is granted the cases read feature in one of their roles they can then access any files API that also has that particular tag securitySolutionCasesFilesRead. The reason we want separate operations is because we split out the delete capability so a user who does not have delete access shouldn't be able to delete cases/comments or their files.

export const CASE_VIEW_ALERT_TABLE_PATH =
`${CASE_VIEW_PATH}/?tabId=${CASE_VIEW_PAGE_TABS.ALERTS}` as const;
export const CASE_VIEW_TAB_PATH = `${CASE_VIEW_PATH}/?tabId=:tabId` as const;
export * from './owners';
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Split this file up to move the file service constants to their own place and moved various other constants to avoid circular references.

await spacesService.create(space);
}

await Promise.all(spaces.map((space) => spacesService.create(space)));
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Made some optimizations to speed up the creation of spaces, roles, and users for the tests

x-pack/plugins/cases/common/constants/mime_types.ts Outdated Show resolved Hide resolved
@jonathan-buttner jonathan-buttner marked this pull request as ready for review February 27, 2023 12:55
@jonathan-buttner jonathan-buttner requested review from a team as code owners February 27, 2023 12:55
@elasticmachine
Copy link
Contributor

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

@elasticmachine
Copy link
Contributor

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

Copy link
Member

@cnasikas cnasikas left a comment

Choose a reason for hiding this comment

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

Nice work! I did a first pass and left some comments.

x-pack/plugins/cases/common/constants/files.ts Outdated Show resolved Hide resolved
x-pack/plugins/cases/common/constants/types.ts Outdated Show resolved Hide resolved
x-pack/plugins/cases/common/utils/api_tags.ts Outdated Show resolved Hide resolved
@@ -25,7 +25,8 @@
"management",
"security",
"notifications",
"ruleRegistry"
"ruleRegistry",
"files",
Copy link
Member

Choose a reason for hiding this comment

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

Do we need to same for o11y and the security solution? I think we would need it only if we need the file service from useKibana. We can do it on the UI PR. Just a reminder. @adcoelho

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hmm I wonder if the build system figures that out because the observability plugin doesn't have "actions" specified in either of their required or optional plugins yet they can still use connectors within cases right?

Copy link
Member

Choose a reason for hiding this comment

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

If I remember correctly "actions" do not export any UI client. We fetch the connectors from our own API. Think about user profiles. We had to put the security everywhere so we use the security UI client. Basically, if we need a service through the useKibana hook it should be part of the kibana.jsonc file and passed in the KibanaContextProvider. Ideally, we should pass the case dependencies in our CaseContextProvider so consumers should not have to pass the dependencies themselves.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah I see. I can go ahead and add it then 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Security solution already has it as required to it's just observability that needs it.

x-pack/plugins/cases/public/files/index.ts Show resolved Hide resolved
x-pack/plugins/cases/server/files/index.ts Show resolved Hide resolved
x-pack/plugins/cases/server/files/mime_types.ts Outdated Show resolved Hide resolved
x-pack/test/api_integration/apis/cases/files.ts Outdated Show resolved Hide resolved
Copy link
Contributor

@semd semd left a comment

Choose a reason for hiding this comment

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

Security Explore changes LGTM

'image/vnd.zbrush.pcx',
'image/webp',
'image/wmf',
];
Copy link
Contributor

Choose a reason for hiding this comment

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

Wow, extensive!!

Copy link
Contributor

@CoenWarmer CoenWarmer left a comment

Choose a reason for hiding this comment

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

LGTM!

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.

Looks good. Great job adding api_integration tests 👍

Copy link
Member

@cnasikas cnasikas left a comment

Choose a reason for hiding this comment

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

Code LGTM 🚀 ! Is there any way I can test it manually?

@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
cases 557 564 +7

Adoption-tracked APIs that are not used anywhere

APIs whose adoption is being tracked and are still not being used. This number should tend to zero.

id before after diff
files 2 1 -1

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
cases 75 77 +2

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
cases 364.0KB 364.0KB +6.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
cases 130.9KB 133.2KB +2.3KB
Unknown metric groups

API count

id before after diff
cases 92 94 +2

ESLint disabled line counts

id before after diff
securitySolution 428 430 +2

Total ESLint disabled count

id before after diff
securitySolution 506 508 +2

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@jonathan-buttner
Copy link
Contributor Author

Code LGTM 🚀 ! Is there any way I can test it manually?

I think we'd need to hit the file service APIs to test it. I can get you those APIs in a bit

@jonathan-buttner jonathan-buttner merged commit 7d81cf2 into elastic:main Mar 2, 2023
@jonathan-buttner jonathan-buttner deleted the cases-files-be branch March 2, 2023 12:35
bmorelli25 pushed a commit to bmorelli25/kibana that referenced this pull request Mar 10, 2023
…152031)

This PR registers three file kinds for cases. One for each instance of
cases (stack, observability, and security). Each solution needs separate
http tags for the routes that are generated by the file service to
implement RBAC.

I refactored the logic to remove some duplication across the three
plugins since we're essentially registering the same http tags with
slightly different names.

This PR shouldn't affect any of the current functionality.

Notable changes:
- I split up the constants.ts file, really the only change is adding the
file kinds logic to generate the http tags the rest is copy/paste
- Refactored the logic to generate the `api` http tags for each plugin
- Registered the three file kinds

Issues: elastic#151780
elastic#151933

---------

Co-authored-by: kibanamachine <[email protected]>
@cnasikas cnasikas mentioned this pull request Apr 3, 2023
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:Cases Cases feature release_note:skip Skip the PR/issue when compiling release notes Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v8.8.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants