We are looking at upgrading to Kinetic 2022-2 in the near future, but while I started testing some conversions on the E10.2 version of kinetic application studio I noticed that the customization layer is stated right in the URL for obvious reasons.
Currently in our Live E10.2, we have many screens that are locked down to be partially read only through customization using the horrible .Enabled property. With the Layers, I tested assigning a layer to a kinetic menu but leaving out a secondary layer, but if I manually replace the layer in the URL with the secondary layer, I am able to access the secondary layer regardless of if it had been associated on the menu deployment or not.
Is there any way to prevent manual overrides or is field security the only way forward with this? I may put in an Epicor Idea to allow layers to be bound to specific menu instances or security groups only if that’s there is not a way already.
We’ve avoided Field Security like the plague in our system so I’m not even sure what/if it’s capable, for instance we currently lock down our part entry to allow engineers to update some of the fields unrelated to costing and our purchasing team to update the fields related to costing, buyer, etc.
We’re worried that a savvy user would be able to swap out the URL layer and get around our current “security” we have by having different menu customizations and the menu is secure through regular security.
EDIT2: Are you suggesting to use Field Security or am I reading it incorrectly?
EDIT: Included pictures show Purchasing being able to edit Unit Price while Engineering cannot
True, even if you could add a security group to a layer, if you switched out your cache or were even more savvy you could probably still get around it.
I am going to look into adding a generic BPM to Ice BO GenXData and see if I can detect if the Customization firing is the same as the one set on the menu, if not, do not load the page… if that’s even possible or even the BO fired on Kinetic.
