Finance would like to limit a user that has access to a security group to not have access to two menu items within that security group. What is the best way to approach this? We don’t want to have to create an entirely new security group just to accommodate this one user’s limited access within that security group.
Can you show a screen shot of an example? Try putting the user in the Don’t allow for that menu item. Not sure if that will work but it should.
thanks kim
Good idea. We’ll have to give that a try.
OK… you asked for the “Best way”… I will give my opinion.
BUT FIRST… i will explain my basic rules
- Most people in a department should have access to all the items in that departments domain… ie… sale get sales, inventory gets inventory
- EXCEPTION is the “Setup” type items… this should be reduced access.
- EXCEPTION to rule 2 are the special “Master” setup items such as Customer, Part, Supplier, etc. There are some things like these that cross over many boundaries.
SO… my rules are:
- create a DEPARTMENT security group for each department
- DeptSales
- DeptProduction
- DeptPO
- create a Department SETUP group for each department
- DeptSalesSetup
- DeptxxxSetup
- Create Program Specific groups for any special master files
- CanEditParts
- CanEditCust
- CanEditSupplier
Now, you have the FOUNDATION for security that is easier to implement.
- each program in the menu gets one (or more, but preferably one) security group
- Remember that the “Special” programs (Part entry) only get the ONE security group (CanEditParts)
- each PERSON is assigned to the security groups that they need to do their job… ie… DeptSales, CanEditParts, CanEditCust
If you follow rules such as above, Later, it will be easier to audit your security to see who has access to what.
This of course can get much more complicated… special Duty separators such as “CanPostInvoices”, “CanShip”, “CanReceivePOs”/“CanEnterPOs”. help to make audits even better.
9 Likes
Be in mind, if Tom is in both “CanAccessProgramX” group (Allowed) and “CannotAccessProgramX” group (Disallowed), he’d have access.
However, if the user “Tom” is added to disallow list, he will then not have access even if he is in “CanAccessProgramX” group
Above are some testing on 9.05.701
Interesting, I wasn’t aware that if you are in a security group that allows you access to a menu item and then also have the specific individual person “Tom” disallowed in that menu item, he will not have access. Does this include all menu items that the security group also has access to that the user won’t have access? We’ve decided to remove the security group access instead of individual specific user no access to the menu item.
The allow/disallow are not stored in a menu item, they are stored in a Security item (i don’t sure if there is an official name)
So if you modify the security of a menu item, you are actually modifying the SEC*** item, and it would apply to all menu item sharing the same Security setting. I think they do list out the menu items assigned to the SEC***.
This is fantastic! Can you give your UOM best practices next?
1 Like
Personally, I never use the “Disallowed” function in the security as it is too confusing. I always like to make everything a positive “Allow” security. I then tie EVERY (DID he say “EVERY”? - YES!) menu option to a security group (this can be done via DMT).
Some people THINK that if they hide group of items by securing the menu (but not the programs) that security is set… BUT… if you dont secure the individual programs, they are not secure. I have gone into systems that were “Secured” according to the IT staff… I was given access to an order entry person’s login, and I was able to get EVERYWHERE by right-clicking through each screen… all the way to GL to show payroll. Lesson learned. Lock down each program, even trackers.
4 Likes
Yup, it is what I’m doing this week, the context menu can sneak into hidden folders. So, EVERY (and we don’t have DMT 
)
I’m looking at Search, there are pretty much information in search result.
Can I create a separate Search on a program for specific security group? I can default customized search to a program but not by menu item/Customization. Different groups shares the same program but I want some of them seeing less info on search screen
(e.g. Pete can view customer name and contact in search result, while Brat can only see the names. Specifically when a simple right click can copy all search result to excel)
Considering replacing the field with a textbox
to make setup screens different you “Simply” need to make different custom versions and put them onto the menu into different security groups:
Example:
- Part - wide open - security group Engineering
- Part - Limited fields available for Planning settings - Security Group Purchasing/Planning
- Part - Super limited - everyone else
But… be careful what you wish for. I have gone down this road, but in the end, people can start playing the blame game on the IT department because you didnt properly tie down that one field…
Instead, I recommend that everyone given access to a program be trained on what to do, and what not to do. Then put in Data BPM to track important fields, so that you can go into a “Trust by Verify” mode.
Lastly, instead of making a bunch of custom versions, I prefer to implement “Security BPMs”… these are special BPMs that enforce security rules… like:
- you may only ADD a part to the part master if you are in the Engineering group
- you may only change the credit limit on a customer if you are in the CreditGroup
- ANYONE can put a customer ON CREDIT HOLD, but only the CreditGroup may take them off credit hold.
BPMs allow much more “logic based” security rather than an all or nothing approach.
1 Like
Your first suggestion…well that is what our Certified consultant did for us initially since the field security was not working.
But along the run it is a pain to maintain… Every change we implement, needs to be implemented on all versions… ;(
So along our migration to 10.2, I suggested to add a verification of the user group the user is partof, and depending on the group, allow/disallow access to specific fields…
But if field security works…no need to have these different versions…
How does Menu Security affect context sensitive menu(aka “right click”) options?
The “Part” program is accessible from several menu items (Order MngMnt -> Setup, Job Mngmnt -> Setup, etc …). When right clicking in a PartNumber field, like in the Order Tracker screen, you can launch Part Maint.
What security settings are used?
Say a user has no access to any of the Setup folders on the main menu, and only has access to various Trackers. Can they still get to the Part Maint screen?
Yes… that is the problem… simply hiding the setup menu does NOT disable all the programs under the setup. you MUST secure EACH AND EVERY PROGRAM in order for the Right Click to be secured. This is because the Right click simply points to a menu option… and the menu option looks at the security assigned to it. If not secured, then you can run the program. That is how you can start with one program (Sales Entry) and get all the way to GL Payroll account info, as long as you can right click to it.
1 Like
What dictates which customization would be used when accessing a program via right-click?
If all of the menu items for “Part” are set to use customization “PM_01”, would that customization be launched via right click?
Right click points to a specific menu path… even though there are many Part programs in various Setup menus… the Right click only points to one of those. It will use whichever customization is on that menu path.
Which one is selected?
If Inv -> Setup -> Parts uses customization “PM_01”, and Order -> Setup -> Part uses “PM_02”, which is the one that gets selected via right click?
Does the location of the program that you’re right clicking in matter?
If Order Entry was launched from Order -> Gen Ops -> Order Entry, and then PartNumber field right-clicked, would the Order-> Setup -> Part (“PM_01”) be used?
Look under Context Menu program, there you can have access to what is currently setup for Part.
1 Like
True dat.
2 Likes
In context menu maintenance, looking at Part.Partnum the process ID specified is IMMT1102, which in the menu maintenance for the menu under Inventory management/setup.
Even though we have 13 Part menu items amongst all our menus, this one is the one getting opened by right clicking.
Pierre