I had always hear rumors that the security would be better in E10 to lock down tabs if you didn’t want users to access a specific tab. I am working on a screen now that I need to make tabs read only. Right now I still only see to go in customization and set that panel (tab) as Enabled to False. Any other ways or is this still the best practice?
That is likely the simplest answer. The only other option would be to make the data readonly using field level security (separate screen) or row rules (customization).
Ok so that is what I trying to do but it won’t stick. When I save and close out and go back in Epicor it is all open. I have done this before in E9 but never in E10.
field level security does not work for us (10.0.700.2) but were by support it was corrected in 10.1 …
You could make a customization that hides the tab(s). Then create a new menu item that uses that customization for whatever screen you are in. Create a new security group called something like ‘RestrictTabs’ and assign that group to your new menu item you created. That way only users that are a member of that sec. group can see and use the menu item that then loads the customization that hides the tab(s) and deny that same sec. group access to the other menu item that shows the tab(s).
Exactly what I did. But when I open the menu item my tabs are open again. I have gone in several times and changed the Enabled to False.
Try “Visible” instead of “Enabled” if you are trying to hide the tab. You can also make the group boxes not Enabled.
Some forms have internal logic that will modify controls. This may be what is happening to you.
I still need them to see the info. I have created a new tab they will have access to to approve the data. It is a quality thing we have to do so they need to see the other tabs to review the data.
Just one tidbit to add. I kind of have hair standing up on my neck when folks describe ‘Security’ and ‘UI’ together. You are not dealing with security if you are only limiting the UI as the place you restrict people from changing data. You REALLY need to look at BPM / Method/Field security if you are serious about SECURITY as opposed to ‘Ease of Use’ in the UI.
As new clients and integration’s continue to appear and evolve, you are only fixing data access via the rich client. Anything else can view / change data unless you protect data access in the server - EWA, MobileCRM, Info Worker, XLConnect, Social, DMT, Search, REST, EDD, Service Connect, JitterBit, the list goes on. That’s why there are the tools available in the server to lock things down.
2 Likes
I understand what you mean. And this new menu item is limited to only a certain security group the problem is Field security is to cumbersome; unless I don’t understand it fully. I have a new tab on my Sales Order Entry called Quality. Quality has to review the SO before shipped. I don’t want anyone in Quality to access anything on the Sales Order Entry except the new Quality tab. this is why I was disabling the tabs. It works perfect in E9 but not working in E10.
1 Like
You know your business more than us so as long as you go in educated, I am happy. 
For example, if you did an integration and someone made a helper app for Quality, then you have two places to make the check. Add another app, etc etc. Yes - I am possibly over engineering for future proofing so feel free to ignore the discussion 
Instead maybe a BPM? (since you are uncomfortable with the field security - understandable since that really feels like a dev or dba UI rather than a power user ui)
On SalesOrder MasterUpdate prevent updates when the user is in a certain group? There may be a couple of methods you need to block changes upon from SO but with that approach, it’s one change for any other UIs.
I am sure others will have some ideas but if we have strayed into over complicating, that’s understandable.
Another possibility is an Updatable BAQ for the Quality people where you only expose the fields they can update. This limits the customization required to the Order Entry Screen. I would augment this with Bart’s idea using a BPM and Security Groups to control updating from all sources.
Mark W.
1 Like
I don’t want any thing complicated or time consuming, but sounds like there may have been changes in E10. In E9 i just mark the groups as enabled FALSE and it worked great. I am guessing since when I create the menu item and I select OrderEntry.dll it is not letting me to lock down the groups or fields I want. Is there a different program that would give me more flexability or am I back to using a BPM or something to lock it down.
Well the menu never locked down the server. The menu going back to V8 was only aui ease of use item. Anyone could hit the server and bypass the menu.
I am not sure how that was horribly marketed but that ignorance in today’s virus and hacking world is a dangerous approach
Is there a way to have multiple customizations on one form and have security groups set up separately for each customization? Or does each customization need its own menu ID?
Make them separate and use menu security.
Technically you could probably cobble something together that would work
the way you describe it, but it would be a mess.
there never has been “tab security” built into E10/Kinetic… but the concept is that you CAN create multiple customizations hiding tabs that you want to hide away, and then putting the mutliple versions on the menu with different security groups assigned to each custom version.
For example, you could create different version of PART maintenance… one for sales, one for purchasing, one for production, one for Engineering… each would have their appropriate tabs/fields available.
1 Like
Wouldn’t having multiple customizations break the “Open With …” functionality?
Sounds like a IUPM (User Interface Process Management) would do the trick.
Put it on the UIO.GetMenu method. Have a condition widget that checks the menu ID and the users sec group membership, and sets the UIMPCallContext.Customization field to the specific ID of the customization to use. Best not to hard code the sec groups in the IUPM. Create a UD table with Keys being: 1) sec Groups, 2) menu ID’s. Then have a field for Customization ID. The IUPM would lookup the secGrp / menuID entry and return the customizationID.
No extra menu items to create of maintain. All users would have the same menu, so the Open With points back to the same menu item. Which form (or customization of that form) to load is determined by the UIPM.
But that would only work if UIPM’s were a real thing. 
This get anyone thinking of a way to implement dynamic menu items?
1 Like
Would it break open with? well… yes and no.
Open With is a context menu. the context menu points to a specific menu option. You can add multiple new open with options to take the user to their specific open with that they need. example: Open With Part for Engineering, open With Part for Sales, etc.
1 Like