I also observed something odd.
Based on the documentation, I would expect groupid should be the unique identifier of the group and memberid would be the unique identifier for the user (entityid) from the entities table. Yet the QV_ENTITY table is being joined to the QV_ROLES table (in your example and similarly in my environment) using QV_ENTITY.entityid = QV_ROLES.groupid. This will produce some interesting results, if any at all.
I think this is intended - The QV_ENTITY table contains both groups and users and then the QV_ROLES table is essentially a bridge from QV_ENTITY to itself, containg the entityid of the user (aliased as memberid) and group (aliased as groupid). So a join on QV_ENTITY.entityid = QV_ROLES.groupid will just return a row for each member of each group.
Presumably this query is performed so you can search for group names as well as usernames - If noGroupMembers = 0 then it will just return the details for the username searched for, otherwise it performs another query to find details for all the users in the group name searched for.
It's a slightly confusing data model, having to join on fields with different names, but it works fine when it generates the right sql. It just needs to either preserve the case of the search string (which it did in QV10...) or do:
... lower(e.name) = 'actohe01' OR lower(e.descr) = 'actohe01' ...