Media library folders beta is live

[Nastia]

Hello, dear community members!

We’re happy to share progress on the very awaited feature - folders in media library.
It allows you to group media assets into folders to organise them as you wish.

The feature is available in Strapi v4.3 beta, to test it please run the following command:

npx create-strapi-app@beta my-project

Check out the user guide for the media library folders to try the feature out.

We would love to meet your expectations for this feature.
Please let us know what you think about it in this tread

[malgamves]

Great release team! Absolutely love this… my first bit of feedback as I test this out is I will need breadcrumbs somewhere in the interface to help me navigate through the folders. I put together a loom to illustrate this.

loom video :))

[Dimitris_Ktr]

This is great, I look forward to utilise this folder feature with the REST API to upload files in folders.

[gustavpursche]

@Dimitris_Ktr Thanks! In the first iteration folders won’t be exposed through the APIs and only used as an internal concept for content-editors.

Can you explain me what you want to build with folders in the API?

[dmurphy779]

I tried using the command npx create-strapi-app@beta my-project and installed the regular 4.2.0 (non-beta). Not seeing folders.

[gustavpursche]

Installing the beta this way only works for new projects. For existing ones you need to manually update your dependencies to: e.g. @strapi/strapi": "4.3.0-beta.1. Make sure to update all @strapi scoped packages.

[LuisAlaguna]

How does it work with GraphQL?

[yomomano]

awesome ! when will it be released?

[gustavpursche]

@LuisAlaguna Folders are an internal concept for now and won’t be exposed through REST or GraphQL. While that would certainly be possible, we wanted to make sure to improve lives of content editors first.

@yomomano At end of July.

[gustavpursche]

@malgamves Good news: since we received the same request about using breadcrumbs for navigation, we have decided to work on another first iteration:

Please note: the design might change till the release. Do you think this would work for you?

[Erik]

This feature looks great. What about managing rights? For some folders, I want to grant public access, for others I would like to grant based on permissions. Is this possible?

[gustavpursche]

@Erik Initially folders won’t have their own permission system and follow the ones assigned to assets instead (e.g. if you are able to delete assets, you are able to delete folders).

For your usecase: do you mean that you’d like to hide certain folders for certain roles?

[Erik]

Hi,

I would like to allow access to some media only when the content has a certain status, it could be from Draft to Published, or another property of that content-type. If the content is in draft, then only certain users would be allowed. The rule is finer than verifying roles.

Given this example: I add a Product with an image, but the product is not yet published, so nobody should be able to retrieve the image via a direct link, by guessing the link. In this case, the image would be posted to S3 private bucket, and then once it gets published I would like the image to be moved to the S3 public bucket where internet access is allowed.

Or vice-versa, I could change the status of a product from published to draft, and thus move the media from S3 public bucket to S3 private bucket. I could also use ACLs to manage the access on object levels inside S3 buckets.

For the moment I have no idea how to expose the direct link to S3 buckets since all data in the bucket would be public . For the moment, the buckets are private, and I have to proxy server the media download from the bucket and decide which ones requires user authentication via checking the status of the product.

So there are many solutions possible for me, but I think for the purpose of strapi, it would be interesting is that on the strapi media library we could have ACLs attached to the library, folder, or object level.

[msoler75]

I’m in same direction in my project. For now I manage folders as a content type with its own Access Control List. This ACL is a bit complex, because I have groups of users (assigned by admin), teams (assigned by users theirselves), and shared folders, all with read/write/admin rights granularity.
I don’t expect that media folders can cover or replace my needs in terms of ACL but it could be expect that basic ACL functionality will be demanded.

[LuisAlaguna]

And how does it work with Cloudinary?

[gustavpursche]

@Erik Thanks for describing your usecase. Right now this is not possible with the media library and it is not planned for the near future. However, we have added it to our internal list of ideas to iterate on.

If you want to create some visibility in the community I encourage you to open a feature request: https://feedback.strapi.io (same for permissons @msoler75).

[gustavpursche]

@LuisAlaguna Since folders only exist programmatically in the database and are not reflected through providers, everything will work as it does currently for cloudinary. If you believe Strapi should start reflecting folders at the provider level (cloudinary, S3 …) I recommend to open a feature request on https://feedback.strapi.io/.

[LuisAlaguna]

It would be good if the folders are also applied to Cloudinary, as it is possible by its API to create folders.

[gustavpursche]

We discussed that at the beginning, but the problem is that each provider has a very different understanding of folders + different concepts for permissions connected to that. This becomes difficult to deal with, if you want to e.g. implement a moveFile function for a provider. In addition once the folder path is part of the asset URL (I’m not sure this is the case for Cloudinary), your file-paths in the frontend might break easily if e.g. a folder is moved somewhere else.

I encourage you to open a feature request at https://feedback.strapi.io explaining your use-case. Requests on that board will be taken into account once we iterate on a feature.

[shestakov_vladyslav]

Very desired feature, thanks