- 🇵🇪Peru krystalcode
Two thumbs up to the point made on #30:
Media has been designed around the idea of it being an independent entity. Media entities can be created independently from anything that may immediately reference them. It does not need to be referenced by anything to be useful to a site builder.
There's plenty of cases where you intentionally want media access to be independent of the entities that reference it. If a solution is designed for what is discussed in this thread, it should be a separate module that you optionally install and definitely not force it on existing applications upon a Drupal core upgrade.
- 🇨🇦Canada teknocat
Further to this, it seems like it would also be prudent to have per media-type view access for any media types that use private files.
We have built a few sites now that need to have private files. Depending on the requirements for any given site, we might use a paragraph type to attach the files to a node, whereby that paragraph type has access restrictions - thus public users can see the node, but only logged in users see the paragraph. Other times we just have a field directly on a node and that node itself might be restricted view access.
So the tree-concept for access checks certainly makes sense, so that if the media entity was attached a field directly on a private node, or to a paragraph that's attached to a private node, then it's access would be restricted based on the root-level entity access.
However, there may still be cases where that doesn't necessarily work, depending on the individual use cases. So being able to set view access by the media type that uses private files would offer that first level of access restriction. I mean, what happens if you detach a media entity with a private file from it's parent entity that had the access restriction on it, but somebody out there still has a link? If the media entity itself is published and "View media" is allowed by anonymous users, they can download it.
Something we developed for a client was a document library, which provided a custom UI in the form of a Javascript Vue app that mimicked the functionality of a file desktop file explorer. This library widget is provided as a Drupal block and can then be added to a node using a block field in a paragraph, allowing the client to create a page with other content to go along with it as they see fit. We like to allow our clients to be able to manage all pages of their site the same way, add them to menus the same way etc to provide a consistent UX throughout the CMS. This doc library block and paragraph type is ONLY available to be added to a node type that is private, but the media entities themselves are in no way associated with the paragraph or the node. It's just a way to provide access to this fancy media browser, thus even if this tree-type access solution was in place it wouldn't work in this case.
This may well be an edge case, but if there were view permissions per private media type that was used to control download access to it's files, then it would be easy. Since we already had a custom module built to provide this custom block widget, we implemented a custom permission for document library access and then implemented the appropriate hooks for media view operation as well as file download with the logic needed to prevent access based on the file and media entity type and whether or not you have the permission.
The logic in the download hook is a bit messy, but it works.
Would like to echo @teknocat.
Ran into this issue after reading through the file module overview and wrongly inferring the 'new & improved' media would behave similarly.
The suggested media_private_access covered my use-case and helped intuitively explain the issue of
- Media entity permissions independent of media usage
- Media entity permission based on media usage
Is there any chance of the per media type access drop-down making it's way into core?