Tab security best practice


(K White) #1

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?


(Jason Woods) #2

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).


(K White) #3

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.


(Pierre Hogue) #4

field level security does not work for us (10.0.700.2) but were by support it was corrected in 10.1 …


(Brandon ) #5

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).


(K White) #6

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.


(Jason Woods) #7

Try “Visible” instead of “Enabled” if you are trying to hide the tab. You can also make the group boxes not Enabled.


(Chris Conn) #8

Some forms have internal logic that will modify controls. This may be what is happening to you.


(K White) #9

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.


(Bart Elia) #10

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.


(K White) #11

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.


(Bart Elia) #12

You know your business more than us so as long as you go in educated, I am happy. :wink:

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 :slight_smile:

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.


(Mark Wonsil) #13

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.


(K White) #14

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.


(Bart Elia) #15

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