Restrict Users to Warehouse Purchase Orders

[Ernst]

Client wants to restrict all staff except 5, to only see warehouse purchase orders, when opening Purchase Order Maintenance. So they cannot see who all our suppliers are.
They probably have 50/50 Warehouse to supplier PO's.

Couldnt see anything in User Group security. I guess I may need to do something in a plugin?

Any ideas?

[Ernst]

OK ive done a plugin, in the readend section, It checks for position2 of staff record, if it does not contain "PO", then I do a read of a warehouse purchase order.

Kinda works OK. The Next previous buttons gave me a headache.

[SBarnes]

Unfortunately there are two properties on the pruchase order that you would have needed to get at at change as shown below, where you could have substituted in a view which did the filtering unfortunatley as you can see they are readonly, if they had backing fields something like shown on this link https://www.c-sharpcorner.com/code/3462 ... ction.aspx could probably have been used change them using reflection but glad to see you made it work.

The other option might have been to have a filter and lock the drop down to that to that for users who can't see everything.

Code: Select all

 Public Overrides ReadOnly Property TableName As String
     Get
         Return "PO_Main"
     End Get
 End Property

 Public Overrides ReadOnly Property RecIDFieldName As String
     Get
         Return "PO_Main.OrderID"
     End Get
 End Property


[Mike.Sheen]

Another approach is to use Row Level Security at the SQL level.

I did a plugin + script a while ago (8 years!) to restrict which debtors a staff member can see - viewtopic.php?f=26&t=553#p1934

Same principle, different table.

The plugin simply at login time records in a table the SPID of the jiwa process and the Jiwa staff member id - the script attached to the plugin creates a predicate function which looks at that table mapping a staff member to a SPID and limits what rows can be seen in the DB_Main table. You'd want to do the same but with the PO_Main table.

[SBarnes]

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?

[Mike.Sheen]

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.

[Ernst]

Thanks for Input, Here is the completed plugin, which works quite well for us. If anybody else needs this.

I couldnt pick up if they had clicked the next or prior button when scrolling. Is there a plugin breakout to determine that?

So ive assumed it always prior button, so if they land on a supplier PO, I just go back to last warehouse PO. Unless there isnt a last one, then I go forward.