davidjgonzalez
commented
8 months ago Have you checked out the newer Content Type asset details selector?
these are maps that drive it (left is mime/type or prefix type, and right is the content type name (which is turned lowercase with - for spaces in asset details)
Unfortunately the original decision to rely on AEM logic for determining this turned out to be a bad decision ... You can use the new Content Type one, or you could make your own selector that you can have full control over; theyre pretty easy to make:
Describe the bug The issue is about asset details page resolution. The asset of type .mp4 was resolved to default details.html page which is not correct and it should be video.html. That happens because of the way how String getAssetTypeFromMimetypeConfiguration(String mimeType) in com.adobe.aem.commons.assetshare.content.properties.impl.AssetTypeImpl is implemented. Service user "mimetype-service" fetches "/mnt/overlay/dam/gui/content/assets/jcr:content/mimeTypeLookup" and then looks for a subnode matching the file extension. For current data in /libs/dam/gui/content/assets/jcr:content/mimeTypeLookup, "Multimedia" is the match for "video/mp4", i.e. mp4.
I solved this issue by overlaying /libs/dam/gui/content/assets/jcr:content/mimeTypeLookup and adding a new "Video" subnode containing a configuration for MP4. In "Multimedia" node, I removed the entry for "MP4".
Important note: for Resource Merger to work properly, "mimetype-service" must be granted access to the overlaid "/apps/dam" node.
Environment
To Reproduce Steps to reproduce the behavior:
Expected behavior "video.html" is expected
Screenshots /libs/dam/gui/content/assets/jcr:content/mimeTypeLookup/Multimedia
Possible fix
"mimetype-service" needs additional read permission on /apps/dam, otherwise the Merger will not work properly
Additional context Ideally, this resolution should be configurable in OSGi configuration.