We are finally getting around to doing some security as we prepare to go live later this year. We are adding a group of new users and we know there are some dangerous screens we want these new users to avoid. Basic Menu security has been helpful, but now with Quote Engineering not so obvious.
How might we hide the Quote Engineering button for those that should not have access? We turned off menu security for the users to the Quote Engineering menu item but since the button exists on the Quote they can still click and access the page.
I assume I could use Application Studio to create a layer that removes the button and assign that layer in the menu where these users would have access, but curious if I can do security on the button itself. I am considering a model that maintains “One Layer to Rule them All and in the SaaS-ness bind them” Maybe that is just wishful thinking and the other option is the way to go, but I have access to a group of Wizards that know deep Epicorial Magic, maybe they can help a fledgling wizard with an incantation or three 
Are you 100% certain you changed the security on the menu item for quote engineering? When I press that button for quote engineering, I still see the menu item ID in the URL, so I would think that as long as you have the security set correctly on the menu item EQMT2015 it should work the way you want it.
Warning… the below includes a multitude of LOTR gifs. But… you asked for it!
One does not simply walk into App Studio control security.
But there is a way.
Prerequisite… create a security group for users you WANT to be able to do engineering on Quote Lines. I have one called SALESMGT, for example.
Unfortunately, user security groups aren’t natively passed into individual forms (that I have found). But you can add a dataview to Quote Entry to do so.
Add a dataview… Use the Guided Setup (Wizard). We only need the UserFile dataview, so you can just check that one.
I wouldn’t check the Save/Delete options here… we have no plans to do either of those.
This will create the UserFile dataview and the corresponding GetByID event.
Change the trigger to after Form_OnLoad, or where ever you find an opening.
Rest Call: Just add the Field Value of Constant.CurrentUserID in the method parameters. You don’t need to make any changes in the request/response areas.
Preview… make sure your event fires and your UserFile dataview is populated.
If so… now we can utilize the new UserFile data.
Enter the Data Rule:
If you look at the page properties for the line “Details” page… scroll down to Advanced and jump into the Tools:
Scroll down to near the bottom of the list… you’ll see the toolQuoteDtlEngineering. And, luckily, it already has a binding we can use.
So, we now create a Data Rule, using QuoteDtl as our action view (since that’s where the target tool is bound).
Add a condition where if the UserFile’s (the new dataview we added earlier) GroupList (which is a delimited list of the CurrentUserID’s security groups) CONTAINS a value of the security group you want to use. Again, I have one called SALESMGT.
… Disable EngineeringTool (which is the column binding of the tool, circled above).
Result:
NOW… one caveat. I was testing with myself… and I have the SALESMGT security group in my profile. But what I really want is to not let users who DON’T have the proper clearance to access the button.
So, go back to your Data Rule and add the “Not” criteria.
~FIN~
That is nice in that the user can tell the button is disabled, but it won’t stop them from using the menu item or entering the URL for quote engineering, so that should be combined with other approaches (service / menu security)
Correct, but she said she already had that portion done.
True, but it sounded like it wasn’t working, and they were just trying to disable the button becuase the menu security didn’t seem to work. In any case, I learned something new from your post, I just wanted to make sure people reading realized the limitations 
Along those lines, Context Menus are also a HUGE loop hole even around Menu Security!
This test (sales) user does not have access to Job Entry or Job Manager:
Oddly, if this user uses the Context Menu for Job Entry, it will open it in Job Tracker (read only)… which is good. They have access to Job Tracker.
But the Context Menu of a part number ALSO includes the Job Manager option
… And it will let them in to Job Manager!
Not only that, but from Job Manager… you can access Job Entry via slide-out panel! Fully active (not a read only tracker view)!
There are so many holes in Epicor security it makes your head spin!
This just ruined my day 
One area we really want to keep people out of is Part entry. We have very ordered numbering process and specific Description naming conventions, not to mention Part UoMs get locked once there is a transaction on a part and you can’t deactivate them very easily until all records are processed.
In Quote Entry the context menu has Part Entry prominently featured
PS I’m a dood not a dood-ette no worries just saying
/me rethinks dog Avatar
I just noticed the new avatar and my heart sank! My sincere apologies!
Well, they may have access to Part Tracker. And if they do, it MAY only give them the tracker view (like the Job Entry context menu gave me the Job Tracker view in my earlier test).
I’m not sure why those menus (which had baked in trackers) appear to work… but others don’t.
But if they gain access to a form which has an app-open type event to Part Entry, they may be able to get through, like I was above in getting to Job Entry.
Thinking about it… a method directive on PartUpdate might be best… the directive can evaluate their security groups and not allow the “update” to proceed. So even if they gain access to the form somehow and make changes, it won’t let them save and update the record.
May be worth looking into.
Not sure if there is a QuoteLineEngineering Update svc?? But you could put up a roadblock there as well. Again, if the user calling the method is a member of the right security group, the update fails.
no worries, my name often throws people off. Many women named Victoria opt to be called some form of Tori, Torie, etc…
I was so happy when Tory Belleci joined Myth Busters, finally a prominent male Tory. Although his real name is Salvatore. Mine sadly is simply “Tory” nothing more, nothing less no matter what my brother says.