So I just had a request to limit order changes except for a couple of people. We’ve had some instances lately where well intentioned people just got into stuff they shouldn’t have and accidentally made changes. They want to be able to control who can create or modify orders. Access to the order entry screen is one part of it, but there are other ways to create orders (specifically case management) and there may be others?
Is there a built in way to do this other than menu security? I’m thinking about adding data directives to the order tables, but I don’t know if BPM is the best way to go. There are lots of things that need to change the order tables normally, so I either have to try and guess the things I need to stop and play whackamole trying to find specific things to stop, or stop everything and create exceptions to let the acceptable things through.
Does anyone have any tips to try and figure out what methods to key off of? Obviously I can’t block of all SalesOrder since other areas will be making changes normally (like shipping). There is a large list of a methods I could use. Is this something were you create a log for a while and see what individual methods are being called and see if you can find some patterns?
Where are you running into trouble with users entering/updating where they shouldn’t be?
I’d say first thing is a conversation with the offenders. You could create trace logs but that would be awful to look through.
Yeah… it’s a bit of tricky one. The order entry person (we only have one “main” one) gets a little picky, so that’s where the request came from. I kind of cringe too, because locking down things usually causes unintended consequences.
My plan to start is to notify on change somehow, (like an e-mail or something) and then she at least knows and then can talk to the offender and figure out what is going on. Maybe that’s enough.
@Banderson the service security gets setup for process. For example, blocking the part.update process stops users from saving changes on parts.
Service security is also how to implement security for the rest api. Bart/Nathan’s novel explains that.
Yeah, I get what it’s trying to do, but fields in the order are changed by other things, so it’s not as simple as the part update process. This might not be the right tool for the job.
service security does work, but if you want “friendly” error messages, you can do the same with a BPM… the BPM can check the value of the security group when someone attempts to save (run Part.Update)… you can then pop up an exception message that says something friendly like “You are not in the correct security group… please contact someone in the Engineering Security group”. Pre-processing BPMs should fire off from REST, DMT, regular UI, or Updatable Dashboards.
I was probably going to ask about that too. My initial testing popped up some less than helpful messages. Not so good when dealing with potentially unintended consequences.
