I need to do some testing to 100% be sure this is what’s happening, but I need to be able to set field security so that the user can’t manually change a value, but a BPM needs to be able to set the value programmatically when they affect the record in certain ways.
I thought field security would work this way, but it also blocks the BPM from changing it as well. Outside of sessions impersonation (which I suppose I could do, but yuck), is there a way that this should be working?
FWIW, I’ve never liked field security because every time I try to use it, there’s some caveat that makes it useless. I was just trying to use the tools that are given to us.
Would it work to just set the field to Read Only in an App Studio layer, rather than using Field Security? Sometimes this is easier than Field Security, as it doesn’t come with so many side-effects. But if it’s something your users will juke around by editing it in a grid or something, it’s not as effective.
I try to keep my security server side so 1. they can’t get around it. And 2. It works in both places. We are mostly in classic, and I don’t want to have to redo everything in app studio either.
“Security” in Epicor is literally primitive… still using Windows NT 3.51 architecture there. It’s all yes or no with no nuance except whatever can be built in using “yes” or “no”.
EDIT: And I agree, the Field Security is even more primitive than the rest of it.
Same, I basically don’t use it anymore because of all the quirks.
In this scenario I’d probably use a pre-proc BPM to secure the field against direct changes by the user, and then have your other pre-proc BPM that adjusts the field fire after the first BPM so it doesn’t get blocked.
Yeah, that’s what I’m gonna do. Just adjusted the BPM that set it to also check for the appropriate group and stop or allow if it’s not the automation that does it.
