Unexpected error message: Lucene Syntax search queries are not supported when property level security is enabled

General
, , , ,
1

Hello,

currently we face the error message Lucene Syntax search queries are not supported when property level security is enabled in our logs which originates from pySearch activity (step 2; a Java step).

I checked all the properties on the corresponding class and non of them had any type of property security (i.e. access when). Same for any type of property security rules.

What could be the root cause of this issue?

Is it possible to modify logs so that the output is more specific (i.e. which property security is meant here? etc.)?

Many thanks in advance.

Edit: After rechecking I found out that we have some access control policies and conditions in place for the corresponding class, however it used to work fine in the past.

2

@RasitE77

I have done a search internally for scenarios of this error, and it does appear you have hit upon a newly-found bug (BUG-695687 - Property Level Security breaks search ootb from 8.6).

When property level security is enabled in Pega 8.6.x, searches will not work out of the box as pySearchWrapper has been updated leverage a Lucene Syntax search query.

I looked around further and found that pySearchWrapper is updating the search string to specifically have it run against property pyLabel. This activity was updated in 8.6 and includes this change, So that appears to be the difference between previous PRPC version 8.5.5 and upgraded 8.7

The code is changing the search string from: SearchString
to: pyLabel:(SearchString)^5 OR (SearchString)

So what this is doing is attempting to “boost” results where the pyLabel matches the search string. This causes those search results to appear higher up in the list than those where the results match with some other indexed property.

With property level security in use, this is not possible.

SOLUTION:

Please update step 3 of pySearchWrapper to set the value of Param.pySearchString to Param.SearchString as it was in earlier version(8.5.5) instead of the out of the box value.

I am attaching picture from prpc version 8.5.3.

WORKAROUND.png
WORKAROUND.png1289×629 66.2 KB

----> Can you test that just to confirm that it works?

We will be creating some documentation around this issue in the near future.

As a side note (and probably not the solution in your instance) , could I confirm what characters you are using in your global search?

Note that colon characters, for example, can cause this type of error. You can replace “:” with a space to avoid this error for other scenarios.

All the search terms/tokens can consist of:

  • Digits
  • Letters
  • Characters: ‘-’, ‘_’, ‘!’, ‘%’, ‘@’, ‘.’

It means that anything what belongs to the list above can be searched. Anything from outside of this list, like space, is treated as a split character and is used to find tokens in property values during indexing.

Please confirm if the pySearchWrapper workaround fixes your issue.

3

@MarijeSchillern many thanks, the fix worked. I did a similar fix when playing around but sometimes the performance of this fix is pretty bad. Will there be a fix with better performance or are my expectations to high ? :slight_smile:

Regarding your side note question:

As a side note (and probably not the solution in your instance) , could I confirm what characters you are using in your global search?

Usually we search digits, numbers and ‘-’ to my knowledge.

4

@RasitE77 I’m glad the workaround worked :slight_smile:

I’m afraid I cannot comment about the Search performance issue you mention. This is not something that came up in the investigation I carried out for your specific error..

As always, if with the update patch performance proves to be a problem feel free to log a support incident for this and our support team will be able to look into this for you.

5

@MarijeSchillern Thanks, it helps.

FYI: for Cosmos REACT it’s in a step 11 in a pyWorkSearch activity.