Can someone advise what the expected behaviour of field security is when it comes to setting field access to ‘read’?
For background:
I’ve set a security group up so only certain users have full access to the LineDetail field on Erp.OrderDtl. All others are set to read. The idea being that the users can add lines to the sales order, but then can’t change the line description, effectively making it static. This works perfectly fine in Live, but with the latest update which is going ahead this weekend, it doesn’t. It now prevents users with read access from adding lines to sales orders completely, as it won’t pull through the part description.
EpicCare believe that it may be the original behaviour was a bug that’s been addressed in the latest release.
Can anyone shine some light on how they use field security? If the new behaviour is how it “should” work, am I going to need to write a bpm to try and control instead?
This is what I’m finding on Sales Orders, which now creates a massive problem for me as I’m going to have to remove the field security to enable any orders to be created as of Monday.
I have a UD field set to Full Masked. I have a BPM checking that field. The server reads it as ******* when a user who is not a security manager updates a record with it and all BPMs that look at that value fail as they are reading the masked value and not the real value.
I have a case open right now where they are arguing with me that that is working as intended. I’m guessing that all of their security behaviors aren’t working correctly, but as usual, that is the claim.
I mean, “Read Only” should mean Read Only. Are we asking for a separate “Create” level. Should Field Security fully implement CRUD? And maybe also View?
That’s never how field security worked in the past. For example, if I have field security on the terms code field in order hed, the person should still be able to create new orders, because the terms code defaults from the customer record. Without being able to support that type of scenario what is even the point of having field security. Not only that but if its true this change was made then that’s a huge change that should have been announced and explained.
This is my point. If it prevents creation, that to me defies the point of having it in the first place. They’ve logged it as a problem ticket, but let’s see what happens.
Quite how this sort of thing doesn’t get picked up internally I have no idea.
I just tested this in pilot by creating a new user with default (read) access to some fields in orderhed and was still able to create new orders when logged in with that customer. I wonder if its an issue with orderdtl specifically?
It’s when you try and add a new Line, whether it’s from Quote or not. Having the LineDesc field on the OrderDtl table marked as Read Only is what triggers the issue.
Ah I don’t have any field security on the orderdtl so that makes sense. Hope they get it fixed, seems even more inconsistent that it works on the header and not the line.
There’s a difference between “System” created, and user created. A user shouldn’t have the ability to create whatever they want, but they should have the ability to trigger the system to create what it deems appropriate. Like having BPM’s change things, but the user controls set to read only.
I wonder if Part on the Fly is causing this. For parts, the description is auto-filled when the PartNum changes. For Part On the fly, there may be a save on OrderDtl, and then a change to description and this might be blocked as a change to a read-only field.
Do we see this behavior on other OrderDtl fields or just PartDesc?
For parts, the description is auto-filled when the PartNum changes. For Part On the fly, there may be a save on OrderDtl, and then a change to description and this might be blocked as a change to a read-only field.