Ask - Test

GroupIdQueryPreFilterContributor does some groupId processing, but for some reason, it updates the original groupIds array, see here. It then breaks the functionality of subsequent contributors.

The real case:

The custom "service builder" based module with the portlet scoped to the actual layout. The groupId of stored entities is actually the scopeGroupId. This design allows reusing the same portlet on multiple pages, each having separate content.

When the search is invoked within the specific layout, it is processed by several filter contributors. Inside the GroupIdQueryPreFilterContributor both groupId and scopeGroupId filters are built, correctly. However, the scopeGroupId value is overwritten to its parent groupId. This modification is then passed to subsequent contributors.

If the search is invoked by regular users, the modified SearchContext is passed to the DefaultSearchResultPermissionFilter. It runs several sub-searches, all with that overridden groupId value, which obviously does not return any results (scopeGroupId filter is set to non-existing value).

In the case of an administrator, that DefaultSearchResultPermissionFilter is not employed. In this case, groupIds modifications have no immediate impact, and expected results are returned.