## Summary
closes; https://github.com/elastic/kibana/issues/173138
Looking into this, it turns out this issue was happening because the
header value for `content-disposition` contained invalid characters
given we were using the filename as is.
See Screenshot resulting from debugging the request;
<img width="846" alt="Screenshot 2024-02-13 at 13 38 53"
src="c1fbc09c-53c3-4d5b-8ba9-8752a56a9a6b">
To fix this, I've opted to leverage the ~package
[content-disposition](https://github.com/jshttp/content-disposition), in
place of some custom approach to fix this~ `res.file` handler which
correctly handles computation for content-disposition in place of
`res.ok` ~and providing our own computation of the value for
content-disposition~.
## Verifying the fix:
- Navigate to cases, (found in the the nav menu for stack management)
- create a new case, if there isn't one you can readily use
- click the files tab and grab an image you'd like to upload, before you
do rename said image to `Screenshot 2023-12-11 at 1 29 07 PM` keeping
it's extension
- on image upload complete, you should be able to view the preview for
the just uploaded image.
<!--
### Checklist
Delete any items that are not applicable to this PR.
- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [ ] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### For maintainers
- [ ] 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)
-->
This PR adds a new API for deleting a file within a case given the file
id.
This API will retrieve the file saved object provided in the query and
perform an authorization check using each file's file kind. It will also
retrieve all the attachments associated with the files and perform an
authorization check for each attachment. This api supports calling it
with ids that only have the file saved objects and not the corresponding
attachments. For the deletion sub privilege to work correctly, it must
have access to updating the file saved objects. Therefore we also had to
give the delete sub privilege all access to the file saved objects
types.
This PR does not contain the logic for deleting all files when a case is
deleted. That'll be completed in a separate PR.
Example request
```
POST /internal/cases/a58847c0-cccc-11ed-b071-4f11aa24310c/attachments/files/_bulk_delete
{
"ids": ["clfr5sdky0001n811gjot7tv5", "clfr5sgru0002n8112t54bave"]
}
```
Example response
```
204
```
Notable changes
- Refactored the delete all comments to leverage the bulk delete API
from the saved object client
- Updated the names of the `api_integration` users and roles to avoid
clashing with the ones in `cases_api_integration`
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
This PR refactors the file kinds to be scoped to cases. Original the
file kinds were `cases`, `observability`, and `securitySolution`. Now
they will be `casesFilesCases`, `observabilityFilesCases`,
`securitySolutionFilesCases` to avoid clashing with file kinds that the
solutions would want to register in the future.
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: https://github.com/elastic/kibana/issues/151780https://github.com/elastic/kibana/issues/151933
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
