FIND ALL, SEARCH_COUNT seems to override READ PROTECT Filter

BenHayat

I just noticed something that oddly surprised me.
The FIND ALL and SEARCH_COUNT combo action disregards READ PROTECT filtering.
I find it to be odd.

If this is a bug, then it has to be in FIND ALL that returns more objects than it should, because the SEARCH_COUNT shows the total counts of objects in the table regardless of the READ PROTECT filter condition.

Is this a bug? I want to run it by you guys before opening a support ticket.

Awaiting your comments.
Thanks!

kklosson

Ben,
Can you provide the protection rule and some context of the BO if required? Protection rules can fool you (they have certainly fooled me before). But my inclination is to review the application of the rule and its implication before suspecting a bug. Happy to help - perhaps a remote session. Sometime a second set of eyes will help.

BenHayat

kklosson wrote
Ben,
Can you provide the protection rule and some context of the BO if required? Protection rules can fool you (they have certainly fooled me before). But my inclination is to review the application of the rule and its implication before suspecting a bug. Happy to help - perhaps a remote session. Sometime a second set of eyes will help.

Thanks for your attention;
I have created a simple BSV test to produce the issue, 7z zip fileattached
Please follow the following steps and you can see the problem;

Install the bsv, login (admin/password)
*) As you have logged in ad admin, click on Step 1 button and add 2 customers. Customer A and customer B
*) Logout as Admin and Login as Customer A (very important step)
*) Click on Step 2 Add Orders to Customer - You will see Customer A only. Go to Edit mode and add 2 or 3 orders
*) While you're still logged in As customer A, click on Step 3 and 4 to see list of POs and counts

*) Now, Logout and Login as Customer B. And got to Step 2 and add 1 order to Customer B.
*) The moment of surprise... Got to step 3 and 4 and you will see the POs and counts of the whole system regardless the READ PROTECT I have put in the PO Object:
If NOT(PO IS NEW) AND PO.ParentCustomer<>LoggedInCustomer Then READ PROTECT PO FROM ALL

And in the SQL tables, the PO as the correct parent:
4635 2 2015-04-23 15:10:27 PO 1 Customer 4632 Orders
4636 2 2015-04-23 15:10:39 PO 2 Customer 4632 Orders
4637 2 2015-04-23 15:39:04 Po 3 Cust b Customer 4633 Orders

The READ PROTECT does not do any filtering for FIND action and you have to use WHERE clause, which defeats the purpose of READ PROTECT filtering, because the WHERE clause can be hacked.

Please review the rules and see what you think. Thank you in advance.

NewCustomerTest.7z

35.56kB

NewCustomerTest.7z

35.56kB

kklosson

According to the BSV, the Customer's AccessLevel is Administrator so the rule is doing its job. I know this is a sample BSV, your application BSV may be different, but your rule in the BSV is also different than stated in the post. In the BSV, the rule is "Protect From All Except Administrator and System. When I changed it to Protect From All, works.

BenHayat

kklosson wrote
According to the BSV, the Customer's AccessLevel is Administrator so the rule is doing its job. I know this is a sample BSV, your application BSV may be different, but your rule in the BSV is also different than stated in the post. In the BSV, the rule is "Protect From All Except Administrator and System. When I changed it to Protect From All, works.

Yes, it my mistake as I was setting up the BSV quickly, so I removed the "Except Administrator and System", but my original problem still has the problem, where the SEARCH_COUNT shows a count of ALL objects regardless of the READ PROTECT condition.

After you removed the "Except Administrator and System", did you click on step 4, logged in by either user? That's where my problem is.

BenHayat

Even the COUNT in the grid disregards the READ PROTECTION filter. In here, I have 6 objects in my table, from different tenant. But when I do a
FIND ALL Programs
SEARCH_COUNT
I get 6 . Here in a screen shot, the grid is showing 2 programs, but the count shows 6.

Don't you think this is a bug?

kklosson

I think it is certainly not what the user expects. FIND ALL should respect the protection rules and I have no evidence that it doesn't. If you you, definitely send the BSV to support. I've never used SEARCH_COUNT and it's possible that it was never designed to respect the protect rules and perhaps support can respond to that issue.

BenHayat

kklosson wrote
I think it is certainly not what the user expects. FIND ALL should respect the protection rules and I have no evidence that it doesn't. If you you, definitely send the BSV to support. I've never used SEARCH_COUNT and it's possible that it was never designed to respect the protect rules and perhaps support can respond to that issue.

Thanks for your response.

So, you also find it odd for "Find All and Search_Count" combo, not to respect Read Protect's condition.

Another point that bugs me, is that, Search_Count actually gives the total number of records in the table. So, If the table has, 5 million records, does it mean, Find ALL has really loaded that many records into the server side memory in order for Search_Count provide a total count? If true, we're going to have some serious memory usage on the server side.

kklosson

On that, I don't know, but logically I would expect SEARCH_COUNT to calculate the number of records found in the FIND considering all aspects of the query, including protect rules.

BenHayat

kklosson wrote
On that, I don't know, but logically I would expect SEARCH_COUNT to calculate the number of records found in the FIND considering all aspects of the query, including protect rules.

We're on the same page my friend. Thanks for shedding your wisdom light on this. I'm preparing an email to support now.
Thank you Sir!

joben

Bumping an old thread here, this is still a problem.

Example:
This query contains 9 records, and all of them are read protected for the user currently viewing it.
No rows are returned, which is good.
Yet it still displays a count of "9".

This leaves me with 4 options:

Ignore it (and make the users annoyed).
Remove the summary count (and make the users annoyed).
Build and maintain a relation that is only used for access levels so that I can do something like:
FIND BO WHERE (LoggedInRegularUser IN BO.HasAccess)
Which is just a lot of hassle.
Create multiple similar queries and let processes handle which one should load.
Simplified example: If RegularUser.AccessChoice='LocationBased' Then DISPLAY 'Query 1' Else
DISPLAY 'Query 2'

Query 1 = Find BO WHERE (Bo.Location=LoggedInRegularUser.Location)
Query 2 = FIND ALL BO

I think I am going to go with option 4 in this case, but I would love a solution where READ PROTECT rules are always respected.

hpl123

joben wrote
I would love a solution where READ PROTECT rules are always respected.

rocketman

I find the logic strange here. The READ PROTECT statement is usually placed in the RULES of the BO, and they don't fire when a query is run and a list is obtained. They only trigger when you enter edit or view mode (or this is my understanding). The protection is not permanently held against a record.

By far the easiest way to do this is a tweak to the query something like WHERE BO.OwnerID = LoggedInRegularUser.ID OR LoggedInRegularUser.AccessLevel = [whatever]

With that, Administrators can see everything, users can only see their own orders

PointsWell

rocketman wrote
The protection is not permanently held against a record.

It is evaluated for every object being loaded. AKA it is a massive speed inhibitor as the rule has to be read n times for every query (where n is the number of instances being returned) before deciding whether or not to show the record in the query.

In terms of speed (for queries at least), it is better to evaluate the condition in the query rather than via PROTECT rules, but that means you have to have the correct query written to ensure that you don't show records that should be protected by accident.

When Vlad implemented the evaluate shortcuts we discussed a variety of different approaches because my queries were being slowed down by the running the rule to determine Show / Hide as well as the SQL to determine every shortcut for a complex BO hierarchy (which had potential to be recursive).