Client-side output files filtering

[psolom]

The type parameter is the legacy from original RichFilemanager
According to the new security model it's not secure to pass parameter to the server in order to set allowed files extensions list. Thus type parameter is ignored in the last versions.

However it might be a good idea to use type parameter for client-side filtering, just to hide non-image files in case the type image is set. It will not affect files list returned in the connector's response. You have to use server-side config for this.

Also, since you may want to define you own extensions list for images filter I think the JSON config file should be extended with filter option, where you can define your own associations. Example:

{
  "filter": {
    "images": ["jpg", "gif", "png"],
    "media": ["mp3", "avi"],
    "custom": ["pdf", "md", "doc"]
  }
}

Raised from psolom/RichFilemanager-PHP#7

[psolom]

Criterias:

1. Filtering should affect both: files tree (left pane) and files view (right pane)
2. The filter should be the upper-level section in the JSON config file, right before viewer section
3. The type query parameter should be renamed to filter

[iruizmar]

I'll do it. Can you assign it to me?

[psolom]

I can't assign you since you are not a creator of this issue. Go ahead eitherway.

[iruizmar]

When a user tries to upload a file that is not in the list of extensions for the current configuration, shall we prevent them for doing it? Or let them do it but don't show them later?

I mean, I added the 'accept' parameter to the file input, but they can change that by selecting "All files" in their file explorer. Also, they will be able to drag any kind of file. What should we do in these cases?

[psolom]

The second option in correct:

let them do it but don't show them later

Your PR should affect client-side solely. Don't involve connectors, please.
Btw, don't bother to minify scripts, I will do it later.

[psolom]

I can see you applied filtering to the fileupload as well.

I don't think we need this because this feature is not intended to be used as restriction. Eventually every user of RFM can change query param filter, so you can't rely on this. Server-side config is the right place for such restrictions.

This feature is for filtering out specific files in folders to display only images or media files. Later we can UI icons to filter lists by mouse click event without changing URL.

Let me know if you can see any case when we need to apply filtering to files upload part.

[iruizmar]

Hello,

I don't fully understand what you mean. Is it the:
$('#fileupload').attr('accept', shownExtensions.map(function(el){return '.'+el;}).join());
part?

What I intended with this was to show the user the subset of file extensions in the browser file explorer. But it is not a restriction indeed, since he can just select "All files" in the explorer.

If you mean the piece of code added to the 'fileuploadalways' and so on events, I was trying to do what we talked about in the PR: let the user upload the files but do not show them in the lists later. The file is correctly uploaded and, if you don't pass the filter query param later, it'll show as expected.

By the way, I found a bug when passing the query param and the filter section is not specified neither in the config.json nor in the config.default.json. It throws an undefined error in the getFilteredFileExtensions function. Shall I push the change to the same branch?

Thanks.

[psolom]

I see, thanks for the clarification. Sounds reasonable.
I haven't tested your code yet, just performed a quick code review, so seems I misunderstood some parts. Ok, leave it as is.

As for the new bug you discovered, create new PR on the "dev" branch, please.

[psolom]

Hey @Saso222
I have greatly exptended the concept of filtering
Now it's possible to apply filtering directly in the UI with buttons in the header.
Capability to perform filtering via URL params remains without changes.
Just note that you have to set "image" insted of "images" filter now.

Changes in UI highlighted on the screenshot:

1. refresh of currently open folder content
2. client-side filtering section

All this will be release in the v2.5.2 soon
You can get an actual code at the "dev" branch.
I would appreciate if you will find an opportunity to test it before release.