[Files] Navigate from the Files Management UI page to the case the file is attached to

[cnasikas]

Users can attach files to cases. The files attached to cases can also be viewed on the Files UI page on the management page. It would be nice if users can navigate from the Files UI page to the case the file is attached to. Although we do not support it at the moment, it may be possible in the future for more than two cases to share the same file. The user should be able to select to which case he/she wants to navigate.

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[sebelga]

In #155179 I've added the option to not list the files in the Files management UI.

The issue here implies that the files management knows about the cases plugin.

Before trying to come with a solution (that would imply some sort of extension point that would render a link with a title) I want to confirm if disabling the files from the management UI isn't enough.

Basically my question is: does it make sense/bring any value to list those cases files in a global Kibana file listing?

[cnasikas]

Hey @sebelga! In 8.8 we disable deleting the files from the management page but we show the files. The reason is that it may be needed to delete files for compliance or performance reasons across Kibana. As there is no way to search for files across all cases, users will have to go case by case to find the file they are looking for. This makes it infeasible with a large number of cases. Also, the global Kibana file listing offers sorting by type or size something that is not possible in Cases at the moment. This way, administrators can find their files quickly and then they can use the API (backend) to delete the file if needed.

The proposal here is the next step where users, after they found their file quickly (with the means described above), they can navigate to the case through the global Kibana file listing and delete the file from within the Case without the need to use the API. This is not urgent. We can wait until we get feedback from users.

The issue here implies that the files management knows about the cases plugin.

I think the files management can be agnostic if we can register our own table buttons and control what will happen if the user clicks on it.

[sebelga]

Hey @cnasikas !

The reason is that it may be needed to delete files for compliance or performance reasons across Kibana.

Not sure I understand that sentence as you have disabled deleting. So this does not apply to cases right?

The proposal here is the next step where users, after they found their file quickly (with the means described above), they can navigate to the case through the global Kibana file listing and delete the file from within the Case

This seems like a very odd solution for users. We asking them to:

• Be in cases UI.
• Then from there, navigate to a different app to search for their cases files
• Then from there, navigate back to cases UI to actually do something with the file (delete it).

At the very least it seems that, in the Case UI there should be a link "See all cases files", that would navigate to the Files management UI and filter down the files to only show the cases files in the table.

If we manage to do that, then I wonder why we would not expose the component with the table filtered down and you would embed that table in the Case UI instead of all this back and forth?

And of course allow to delete a file directly from the table 😊

[cnasikas]

Hey @sebelga! Sorry for the late reply.

Not sure I understand that sentence as you have disabled deleting. So this does not apply to cases right?

Yes, we disabled deleting as an interim solution until we have something better. We did it to reduce the likelihood of having stale files on a case but we believe that for compliance or performance reasons, we need to offer a way for the users to do it quickly and easily.

I think the problem we are trying to solve with this issue is:

1. Administrators need to search files across all cases. Cases do not offer that.
2. Administrators need to be able to delete files easily and quickly across all cases. As the deletion is disabled for case files they have to find the case where the file is attached to and delete it from there.

I can see the following solutions:

1. Allow deleting from the Files management UI. This will create stale files in Cases.
2. Allow deleting from the Files management UI but provide hooks on the backend so Cases can handle stale files.
3. Do not allow deleting from the Files management UI but provide searching files across all cases from the Cases UI. As searching across multiple SO at the same time (assuming we want to offer searching of Cases + files from the same search bar), and keeping pagination and filtering is complex, I am not sure when we will be able to provide that.
4. Have a dedicated view in the Cases UI only to search files across all cases. We can use what you proposed, use the table used in the Files management UI 🙂. In the future, we intend to provide rich searching capabilities where users can search across multiple entities attached to a case from the same search bar. For that reason, I would like to avoid this solution and think about searching holistically.
5. Do not allow deleting from the Files management UI but provide a way to go to the case the file is attached to so users can delete it from there.

I am not sure which is best, to be honest. What do you think? @shanisagiv1 @heespi What is your opinion on this?

[sebelga]

For me the best is always to avoid back and forth between apps and make the actions that the user needs to do as close as possible from where they are.

This means embedding a FileListView in the cases UI and let you customise the behaviour when clicking delete button (e.g. Open a modal and warn the user that deleting the file will remove it from the case "123")

The day you have the enhanced search and listing of cases files you can replace the shared component with your own.

With that said comes the time of priorities and how fast we need to come with a solution 😊 I am not sure that allowing extension point to the FileManagement UI is actually much simpler than making the table embedable.

[shanisagiv1]

These are my 2 cents: I'd say that search/querying for a particular file by name cross cases is a minor use case that is probably performed by admins/leaders and not by the end users (Noc/Soc analysts), so ideally as a case management solution, I'd expect users to delete files directly from the case view. And for the edge case of searching cross cases, users can leverage the File Management UI. and we definitely need the link to the original case in order to complete the flow and delete the case.

[sebelga]

And for the edge case of searching cross cases, users can leverage the File Management UI. and we definitely need the link to the original case in order to complete the flow and delete the case.

Trying to understand priorities and needs: does the fact that it is an "edge case" means it is not a high priority for your team and can be deferred after more urgent serverless work that SharedUX has?

[cnasikas]

Yes, it is not a high-priority item and can be deferred after the more important serverless work. Thanks, @sebelga for your time and understanding.