SELECT COUNT(*) as count
FROM patient
WHERE PatStatus NOT IN (3, 4)
AND (
CONCAT(TRIM(FName), ' ', TRIM(LName)) LIKE '%carole%'
OR Email LIKE '%carole%'
OR HmPhone LIKE '%carole%'
OR WkPhone LIKE '%carole%'
OR WirelessPhone LIKE '%carole%'
)
Good morning. The Open Dental API screens all payload queries in Queries POST and Queries PUT ShortQuery request to be read-only (or on temp tables). It also screens out SQL actions that are inappropriate to perform via the API, such as the SLEEP command.
The reserved word "ROLE" is used to view, create, or revoke permissions for mysql users. Naturally, this is inappropriate to perform via the API. The word "ROLE" is used with the keywords "CREATE", "DROP", "SET", or "RESET". Because those keywords are allowed on temp tables, we added "ROLE" to our list of forbidden words. Additionally, it is designed this way because it can't effectively screen "CREATE ROLE" or "CREATE /*comment*/ ROLE" without looking for just "ROLE".
I understand the limitations of your query API, but if you're going to search for the text "role," could you at least make it "freestanding," prefixed by a non-word character or something sane to prevent this sort of failure? This behavior is different for (eg) SET, searching for a patient named Seth or Rosette does not have the same problem.
I realize failed to mention in my last post that I intended too further look into our screening logic to see what we can (safely) do. I will update this thread when I do. However, it is lower priority than API Feature Requests.
We have completed this feature request, and the implementation is live on our beta. The query screening algorithm has been enhanced to not falsely flag reserved or forbidden keywords if they are contained within other words. Your examples of “ROLE” in “Carole” or “SLOW” in “John Oslow” will now pass the screening.
As of Februrary, this was listed as in beta, I assume at some point after it was promoted. We are still encountering the issue, though. Search was again, for Carole.
ETA: This log is from 2025-07-26T00:48:28.709790318Z
Attachments
Screenshot 2025-07-29 at 11.06.53 AM.png (22.97 KiB) Viewed 48002 times
As of Februrary, this was listed as in beta, I assume at some point after it was promoted. We are still encountering the issue, though. Search was again, for Carole.
ETA: This log is from 2025-07-26T00:48:28.709790318Z
Good morning graham_mueller,
Enhanced queries screening was implemented in version 24.4.23. What version are you on? What does the exact query you are running look like?
Ah, I had thought this filtering was done in the OpenDental central API layer. I am not sure what that clinic is using, but presumably lower. I guess we'll have to add a workaround for any clients that are below that.