Customising the index for the Asset Finder

[taryna71844708]

Hi All,

I have a requirement to exclude certain DAM asset folders from the Asset Finder search results when content authors are page authoring in edit mode. These are folders that are either archived or are draft / work-in-progress assets. For reference, this is where I want to exclude these assets from:

However, I do not want to exclude these results from the general search within the DAM interface, as I want archived / WIP assets to be discoverable in the DAM generally:

I think that I can do this by editing the oak indexes with excludedPaths, however when I edit the damAssetLucene index with @excludedPaths='/content/dam/archive', then it excludes the assets from both scenarios above, which makes the content non-discoverable. I just want to exclude it from being used in content authoring pages.

Is there a way to have the Asset Finder run off a different Lucene index?  Or is there a better way to do this?

Thanks!

[arunpatidar]

Hi,

Simply add  hidden=(Boolean)true property to archive folder or other folder to hide all the assets for content editing.

[taryna71844708]

Hi Arun,

Thanks for your reply!   I've had a go at setting hidden=true, however it hides the folder from both search interfaces I've mentioned above - the Asset finder in edit mode and the DAM search. It even hides the folders from the interface (even from the Admin user), however I want this content to be there and available for content creators to browse and edit.  I just want to prevent content authors being able to use these images to author pages because these images are either a) in working state and not ready yet or b) old.

I've also thought that I could do this with a property isReady=true, but I have the same question about that - is there a way to make this applicable for the content author AssetFinder search, but keep it in the DAM search.

[arunpatidar · Accepted solution]

Then you need to overlay the component which render image in search.

http://localhost:4504/bin/wcm/contentfinder/asset/view.html servlet gets the results in content authoring interface and each result is in format of cq/gui/components/authoring/assetfinder/asset you can overlay this to add condition based on editor/URL and add remove this as part of result or overlay .

[taryna71844708]

Thanks that worked.  I overlaid the asset.jsp, and added a customisation to check for the node path;

String nodePath = assetNode.getPath();

if(nodePath != null) {

    if(nodePath.startsWith("/content/dam/archived"))  {
    displayClass = "hidden";
}

Then in the coral card i added the display class, essentially just hidden if I don't want it available to content authors;

<coral-card class="editor-Card-asset card-asset cq-draggable u-coral-openHand <%= displayClass %>" >

[taryna71844708]

Hi arunpatidar26​,

I actually have a follow up question about excluding ‘draft’ or ‘working’ state assets from the Asset Finder.  The JSP used to render content fragment cards is different to the asset.jsp, so my draft and working content fragments are still displaying in the Asset Finder search results. 

The JSP that is rendering the CF cards is: /libs/dam/cfm/components/v2/asset/asset.v2.jsp, however when I overlay this to /apps/dam/cfm/components/v2/asset/asset.v2.jsp and make changes it doesn’t actually get overlaid.

Is there something unique about overlaying that file?  It is greyed out in the JCR, which I believe is Adobe's way of signalling that this is a deprecated file.

[arunpatidar]

Hi,

The overlay should work as v2 node is mark as granite:internalArea.

In order to make it safer and easier for customers to understand what areas of /libs are safe to use and overlay the content in /libs has been classified with the following mixins:

• Public (granite:PublicArea) - Defines a node as public so that it can overlaid, inherited (sling:resourceSuperType) or used directly (sling:resourceType). Nodes beneath /libs marked as Public will be safe to upgrade with the addition of a Compatibility Package. In general customers should only leverage nodes marked as Public.
• Abstract (granite:AbstractArea) - Defines a node as abstract. Nodes can be overlaid or inherited (sling:resourceSupertype) but must not be used directly (sling:resourceType).
• Final (granite:FinalArea) - Defines a node as final. Nodes classified as final cannot be overlaid or inherited. Final nodes can be used directly via sling:resourceType. Subnodes under final node are considered internal by default
• Internal (granite:InternalArea) - Defines a node as internal. Nodes classified as internal cannot be overlaid, inherited, or used directly. These nodes are meant only for internal functionality of AEM
• No Annotation - Nodes inherit classification based on the tree hierachy. The / root is by default Public. Nodes with a parent classified as Internal or Final are also to be treated as Internal.

Please find more about content classification at  Adobe Experience Manager Help | Sustainable Upgrades

How do you add image in CF? using RTE?  CF RTE uses to pick http://localhost:4504/aem/assetpicker?mode=single&assettype=images images.

[taryna71844708]

Hi Arun,

Right, yes its marked as granite:InternalArea so that would explain why the overlay is not working because in your definitions "Nodes classified as internal cannot be overlaid, inherited, or used directly."

Does this mean that the Asset Finder for CF's cannot be customised? I would have thought this would be common to need to overlay.  If there is no way to overlay I will go through Adobe Support to request a product patch.

[arunpatidar]

Yes, You can open ticket for specific use cases.