Dynamic Media Viewer Presets Not Fully Loading due to rep:policy Node | Community
Skip to main content
A
Abhishek.Arora
Level 1
June 11, 2026
Question

Dynamic Media Viewer Presets Not Fully Loading due to rep:policy Node

  • June 11, 2026
  • 1 reply
  • 20 views

Hi Community,

We recently encountered an issue with Dynamic Media Video Viewer Presets on our AEM 6.5.21 and wanted to share our findings in case others run into something similar.

Issue

In the Dynamic Media component, one author was able to see all custom Video Viewer Presets, while another author could see only a subset of the available presets.

The behavior was inconsistent across users even though the presets existed and were correctly configured.

Investigation

After comparing permissions and user groups, we found that the affected user was a member of the Administrators group.

While authoring the Dynamic Media component, errors were appearing in the logs. The issue was traced to:

/libs/dam/components/scene7/common/viewerpresetdatasource/viewerpresetdatasource.jsp
 

 

The JSP iterates through the preset nodes and attempts to retrieve:

preset.getNode(Node.JCR_CONTENT)

For administrator users, the iteration also includes the rep:policy node because they have permission to view it. Since rep:policy does not contain a jcr:content child node, the code throws an exception, causing the datasource processing to terminate early. As a result, only a partial list of viewer presets is displayed in the Dynamic Media component.

Probable Fix

The issue can be resolved by overlaying the datasource JSP and adding a check to skip rep:policy nodes during iteration:

  if (preset != null && !preset.getName().contains("rep:policy")) {
                      Node node = preset.getNode(Node.JCR_CONTENT);

Questions

  • Has anyone else encountered this issue with Dynamic Media Viewer Presets?
  • Is there an Adobe-recommended fix or hotfix available for this behavior?
  • Has this been addressed in newer AEM service packs or AEMaaCS?

Any insights would be appreciated.

Thanks!

1 reply

v-lazar
v-lazar
Level 2
June 11, 2026

​@Abhishek.Arora that pattern shows up every time a JSP or servlet iterates Node.getNodes() without filtering. rep:policy and related system nodes (rep:cugPolicy, rep:repoPolicy) are visible to admins but not to non-admins, which is exactly why only admins see the truncated list.

Two ways you can try to filter in the overlay

  1. Filter by name prefix. Skip any node whose name starts with rep:. (This should cover common cases)
  2. Filter by expected primary type. Inside the loop, check child.getPrimaryNodeType().getName() and continue if it is not the viewer preset type. (Bit more careful approach for the node names that could be introduced in the future)

Also check if the rep:policy on this exact preset path is intentional. If it was added by accident through a deployment or a Sling Repository Initializer entry, removing the unintended ACL is cleaner than overlaying the consumer code. If folder-level ACLs legitimately cascade here, the overlay is the right path.

 

On hotfix and SP coverage, this class of bug has appeared in different DM datasource JSPs over the years. Try opening Adobe Customer Care, they sometimes ship a code-level hotfix rather than asking you to overlay.

 

If you can share the stack trace, we can confirm which line throws and whether other DM datasource JSPs in your codebase share the same iteration pattern.

https://www.linkedin.com/in/viktor-lazar/ | https://cyber64.com/insights
    Terms & ConditionsAccessibility statement

    Loading footer...