SBarnes wrote:Something going forward might be an event on the Find method of BusinessLogic.Maintenance, that gave you the final SQl by reference before it runs?
Perhaps, although it gets messy as we already dynamically fiddle with the query used in Find based on a bunch of things, so if we introduced an event which allowed someone to modify that query they'd want to use the TSQL parser to properly inject their conditions into the query.
We already have a BaseFindSQLQuery and also FixedFilterString property in the business logic which is used by Find to build the SQL query used.
FixedFilterString is probably the best choice - in fact in purchase orders we already use that to filter PO_Main.OrderType based on whether it's a normal PO form loaded or the back to back.
Ernst already has arrived at a solution, so I won't invest in coming up with a plugin to use FixedFilterString - but I believe that would be the easiest and cleanest solution - but would require also doing the other bits outside of just modifying the query used by Find - such as disabling the New supplier PO function (personally I'd just throw an exception within the CreateStart event and not bother disabling the ribbon tool option - let them have a meaningful reason why they cannot create a new supplier PO.
I'd probably also want to throw an exception in the ReadStart event if a quick and dirty read-ahead of the PO revealed the PO wanting to be read was a supplier PO and the user was not privileged to see supplier PO's - that would cover drill-downs from other places.
And on the topic of privileges - it would also be best to use an abstract permission to control which staff members are / are not allowed to see supplier PO's - that way the customer can add or remove privileged users / groups themselves. Create a new abstract permission for the form, and that is what is used to determine if the user has permission or not.