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!
FIND ALL, SEARCH_COUNT seems to override READ PROTECT Filter
Re: FIND ALL, SEARCH_COUNT seems to override READ PROTECT Fi
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.
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.
V8.8
MySQL, AWS EC2, S3
PDFtk Toolkit
MySQL, AWS EC2, S3
PDFtk Toolkit
Re: FIND ALL, SEARCH_COUNT seems to override READ PROTECT Fi
Thanks for your attention;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.
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.
- Attachments
-
- NewCustomerTest.7z
- (35.56 KiB) Downloaded 1381 times
Re: FIND ALL, SEARCH_COUNT seems to override READ PROTECT Fi
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.
V8.8
MySQL, AWS EC2, S3
PDFtk Toolkit
MySQL, AWS EC2, S3
PDFtk Toolkit
Re: FIND ALL, SEARCH_COUNT seems to override READ PROTECT Fi
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.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.
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.
Re: FIND ALL, SEARCH_COUNT seems to override READ PROTECT Fi
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?
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?
Re: FIND ALL, SEARCH_COUNT seems to override READ PROTECT Fi
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.
V8.8
MySQL, AWS EC2, S3
PDFtk Toolkit
MySQL, AWS EC2, S3
PDFtk Toolkit
Re: FIND ALL, SEARCH_COUNT seems to override READ PROTECT Fi
Thanks for your response.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.
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.
Re: FIND ALL, SEARCH_COUNT seems to override READ PROTECT Fi
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.
V8.8
MySQL, AWS EC2, S3
PDFtk Toolkit
MySQL, AWS EC2, S3
PDFtk Toolkit
Re: FIND ALL, SEARCH_COUNT seems to override READ PROTECT Fi
We're on the same page my friend. Thanks for shedding your wisdom light on this. I'm preparing an email to support now.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.
Thank you Sir!
Re: FIND ALL, SEARCH_COUNT seems to override READ PROTECT Filter
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:
1. Ignore it (and make the users annoyed).
2. Remove the summary count (and make the users annoyed).
3. 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.
4. 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.
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:
1. Ignore it (and make the users annoyed).
2. Remove the summary count (and make the users annoyed).
3. 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.
4. 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.
Re: FIND ALL, SEARCH_COUNT seems to override READ PROTECT Filter
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
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
Rocketman
V8.7 Developer Edition. Server 2016 Standard edition. MySql 5.5
V8.7 Developer Edition. Server 2016 Standard edition. MySql 5.5
-
- Posts: 1460
- Joined: Tue Jan 24, 2017 5:51 am
- Location: 'Stralya
Re: FIND ALL, SEARCH_COUNT seems to override READ PROTECT Filter
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).