-
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] Integrating file service and registering file kinds #152031
[Cases] Integrating file service and registering file kinds #152031
Conversation
x-pack/test/cases_api_integration/security_and_spaces/tests/common/files/apis.ts
Outdated
Show resolved
Hide resolved
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)) |
There was a problem hiding this comment.
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
)?
There was a problem hiding this comment.
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'; |
There was a problem hiding this comment.
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))); |
There was a problem hiding this comment.
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
Pinging @elastic/response-ops (Team:ResponseOps) |
Pinging @elastic/response-ops-cases (Feature:Cases) |
There was a problem hiding this 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.
@@ -25,7 +25,8 @@ | |||
"management", | |||
"security", | |||
"notifications", | |||
"ruleRegistry" | |||
"ruleRegistry", | |||
"files", |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 👍
There was a problem hiding this comment.
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.
There was a problem hiding this 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', | ||
]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, extensive!!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this 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 👍
There was a problem hiding this 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?
💚 Build Succeeded
Metrics [docs]Module Count
Adoption-tracked APIs that are not used anywhere
Public APIs missing comments
Async chunks
Page load bundle
Unknown metric groupsAPI count
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: |
I think we'd need to hit the file service APIs to test it. I can get you those APIs in a bit |
…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]>
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:
api
http tags for each pluginIssues: #151780 #151933