Suggestions query returns no result

[Magicr]

Hello,

in one of my project it contains a searchbar with search suggestions. The underlying query is

select [rep:suggest()] from [nt:unstructured] as a where suggest('dual') AND ( ISDESCENDANTNODE('/content/sites/myPages/pageA') 
       or ISDESCENDANTNODE('/content/dam/myPages/pageA'))

There also exists two usergroups. When this query is executed in context of usergroup one, AEM returns a result list with seven entries. When the same one is executed in context of usergroup two, AEM returns an empty result list. Both usergroups have at least read permissions in folder 'content/sites' and 'content/dam', because pages and containing asstes are visible in webbrowser.

I think, this is an issue of permissions. Though, I don't know how solve this issue.

Thanks inadvanced.

P.S.: In case the tag is not visible, I'm using AEM 6.5

[VishalKa5]

Hi @Magicr ,

Problem

Your rep:suggest() query returns results for one usergroup but empty results for another in AEM 6.5, even though both groups have read permissions on the folders and can view content in the browser.

Query:

select [rep:suggest()] from [nt:unstructured] as a 
where suggest('dual') 
AND (ISDESCENDANTNODE('/content/sites/myPages/pageA') 
     or ISDESCENDANTNODE('/content/dam/myPages/pageA'))

Root Cause

The suggest function filters results based on user privileges at the Oak index level. In AEM 6.5, even with folder-level read access, the Oak permission system evaluates suggest queries differently than regular browsing. The suggest query requires explicit, unambiguous read permissions at the node level, not just inherited folder access.

Solution

Most Common Fix (Primary Solution)

Grant explicit permissions to usergroup two instead of relying on inheritance:

1. Navigate to Tools > Security > Permissions (Touch UI) or http://localhost:4502/useradmin (Classic UI)
2. Select usergroup two
3. Add explicit jcr:read permissions on:
   • /content/sites/myPages/pageA (with recursive/child permissions)
   • /content/dam/myPages/pageA (with recursive/child permissions)
4. Ensure the permissions include child nodes

Additional Troubleshooting Steps

1. Verify ACL Order and DENY Rules

In AEM 6.5, ACL evaluation order is critical. The sequence of ALLOW/DENY policies matters - if DENY is placed after ALLOW in the ACL sequence, access will be blocked.

Check for:

• Inherited DENY permissions from parent groups
• DENY entries at parent node levels (/content, /content/sites, /content/dam)
• Conflicting group memberships where one group grants access and another denies it

How to check:

• Use CRXDE Lite → Select node → Permissions tab
• Look at the ACL order from top to bottom
• The first matching ACL entry is applied

2. Check Fine-Grained Oak Permissions

AEM 6.5 uses Oak's fine-grained permission model. Ensure usergroup two has:

• rep:readNodes privilege
• rep:readProperties privilege

These can be separate from generic jcr:read in Oak's permission model.

How to verify:

1. In CRXDE Lite, select /content/sites/myPages/pageA
2. Go to Permissions tab
3. Check "Effective Permissions" for usergroup two
4. Verify both node and property read privileges are granted

3. Review rep:glob Restrictions

Look for rep:glob or other restrictions in usergroup two's ACL entries that might limit access in ways affecting the suggest query but not regular browsing.

Example problematic restriction:

Path: /content/sites/myPages
rep:glob: */jcr:content/*

This would allow access to jcr:content nodes but might block other node types needed by the suggest query.

How to check:

• Navigate to Tools > Security > Permissions
• Search for usergroup two
• Examine each ACL entry for "Restrictions" column
• Look for rep:glob, rep:ntNames, or rep:prefixes values

4. Compare Effective Permissions Between Groups

Use impersonation to verify what each usergroup can actually access:

1. Open CRXDE Lite
2. Go to Tools > Impersonate
3. Enter a user from usergroup two
4. Navigate to /content/sites/myPages/pageA and /content/dam/myPages/pageA
5. Check the Permissions tab for "Effective Permissions"
6. Compare with usergroup one's effective permissions

Look for differences in:

• Missing jcr:read privilege
• Any DENY entries
• Inherited permissions

5. Check Lucene Index Configuration

In AEM 6.5, ensure the suggest index is properly configured and accessible:

1. Navigate to /oak:index in CRXDE Lite
2. Find the Lucene index used for suggestions (typically damAssetLucene or a custom index)
3. Verify there are no access restrictions on the index definition itself
4. Check if the index has suggest node configured with proper analyzer settings

6. Verify No User-Level Permission Conflicts

In AEM 6.5, user-level permissions take precedence over group permissions. Check if:

• Individual users in usergroup two have conflicting permissions set directly on their user accounts
• There are DENY permissions set at the user level that override group ALLOW permissions

Testing Your Fix

After making changes in AEM 6.5:

1. Clear user session: Log out and log back in as a usergroup two user
2. Test the query: Re-run the suggest query in Query Performance Tool
   • URL: http://localhost:4502/libs/granite/operations/content/diagnosis/tool.html/granite_queryperformance
3. Check logs: Monitor error.log for any access denied messages
4. Verify in browser: Test the search suggestions feature in the actual application
5. Use Explain Query: Check if the query plan shows proper index usage

Best Practices for AEM 6.5 Permissions

• Always assign permissions at the group level, never directly to users
• Use ALLOW permissions; minimize DENY usage
• Keep the permission model simple and clear
• Grant least privileges necessary for each role
• Document your permission structure for maintenance

Common AEM 6.5 Permission Pitfalls

1. Inheritance assumption: Assuming inherited permissions work the same for all query types
2. ACL order ignored: Not considering the evaluation order of ACL entries
3. User permissions override: Forgetting that individual user permissions override group permissions
4. rep:glob misuse: Using overly restrictive rep:glob patterns that block legitimate access

The key takeaway: In AEM 6.5, suggest queries require explicit, unambiguous read permissions at the node level. Inherited folder-level permissions are often insufficient for Oak index-based queries.

Thanks

[ManviSharma]

Hello @Magicr ,

You actually ran into a limitation of the CF Model editor, not something you can “fix” with a config tweak.

- In content fragment models only the top-level field is supported as required (via the Field required checkbox). The editor / validation logic is not built to handle required="on" on the child controls of a multifield.

When you add that property manually on the child textfield node in CRXDE, the HTML gets the required attribute, but the CF editor’s validation isn’t re-initialised for items that are added dynamically to the multifield ,that’s why:

- After you click Add, no “Must fill” appears, and after a full page refresh, the browser’s built-in validation finally kicks in and shows the message.

So this behaviour is expected/unsupported with the current implementation.

-> You can use the supported “Field required” on the multifield itself or, 

add custom validation outside the CF Model editor

>For example: Validation in a workflow step that checks the CF content.

-> But there is no OOTB way to make each child textfield in a CF multifield behave as a required field at add time without the refresh. If this requirement is important for your project, the official path would be to log an enhancement / support ticket with Adobe so engineering can consider adding support for child-level validation in CF multifields in future.

[Magicr]

Thanks for you answer. At least for me, I don't use content fragments in my project.

[Magicr]

I think you meant the thread https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/the-quot-must-fill-quot-re... for your answer.